Gestión de Proyectos en Organizaciones y Documentación (Módulo 3)

La gestión de proyectos en las organizaciones y la documentación Su estructura impresiona. Un ediﬁcio de terminal aérea con una entrada con enormes extensiones de vidrio y una salida a una gran estación de trenes por debajo que se conecta con una plaza en frente. A un lado, se alza un elegante hotel y todo parece estar bien conectado, en términos de movilidad, a una autopista. Pero haces una pausa, miras a tú alrededor y solo escuchas silencio. Esta descripción hace referencia al Berlín Brandenburgo o BER, el nuevo aeropuerto internacional de última generación, construido para marcar el resurgimiento de la Alemania reuniﬁcada como un destino global. Costó miles de millones y se suponía que se completaría en 2012, pero nunca se inauguró. BER es para Alemania un símbolo de la catástrofe de la ingeniería. Es un "trauma nacional" y una forma de "aprender cómo no hacer las cosas", dice el experto en infraestructura global, Bent Flyvbjerg. Ningún pasajero salió alguna vez de la estación de tren, que actualmente hace rodar solo un tren fantasma por día para mantener el aire en movimiento. Nadie se ha alojado en el elegante hotel de aeropuerto, que cuenta con un personal mínimo para desempolvar las habitaciones y abrir los grifos para mantener el suministro de agua en movimiento. Si entras a este gran ediﬁcio de la terminal, la atmósfera espeluznante se intensiﬁca. Se les da una rotación diaria a enormes cintas de equipaje para evitar que se deterioren, ya que varias de ellas están diseñadas para procesar llegadas constantes. Vueltas y vueltas sin sentido: nunca cargaron una sola pieza de equipaje real. Las pantallas muestran vuelos que llegan y salen, pero utilizan datos de otros aeropuertos de otras partes de Berlín. Y otras que fueron probadas para usarse en la apertura del aeropuerto, ahora debieron ser reemplazadas o se deterioraron sin haber mostrado nunca un aterrizaje o un despegue. La compañía que gestiona el aeropuerto promete que ﬁnalmente abrirá en 2020, llegando al menos 8 años tarde y con miles de millones por encima del presupuesto. (Bowlby, 2019, https://www.bbc.com/mundo/noticias-48814654). Caso de estudio: operación orientada a proyectos AIM-2X La gestión de proyectos en las organizaciones Referencias Lección 1 de 3 Caso de estudio: operación orientada a proyectos AIM-2X Operación orientada a proyectos. AIM-2X C O N T E XT O D E L C A S O La industria de la venta minorista es una de las que se encuentra en estado más crítico en lo relacionado al control de costos y la velocidad de respuesta a nuevas oportunidades de negocio y crecimiento. En estas organizaciones, el sector de tecnologías de la información (TI) debe brindar sus respuestas al ritmo requerido por el negocio o, de otra manera, se convierte en un obstáculo para el propio negocio. Los sistemas de ventas minoristas exigen respuestas muy rápidas y sistemas informáticos muy ágiles. (Martinez, 2004, https://www.pmi.org/learning/library/project-oﬃcemedium-sized-companies-1853). Figura 1: Características del cliente Fuente: adaptación propia con base en Martinez, 2004, https://www.pmi.org/learning/library/project-oﬃcemedium-sized-companies-1853 Introducción AIM es el nombre de fantasía de una empresa que se dedica a la venta minorista (retail) de productos de higiene personal y limpieza. Esto encara un ambicioso proyecto de crecimiento de su capacidad operativa al doble (2x) en un horizonte de 5 años. Por el tipo de negocio, el Área de Tecnologías de la Información de AIM deberá evolucionar de acuerdo al crecimiento esperado para el resto de las áreas, o proporcionalmente a ellas. La Gerencia General, al igual que la Gerencia de Sistemas e Informática, se enfrenta con la problemática propia de un proyecto sin precedentes para la organización. Los temas que surgieron en una reunión previa al lanzamiento del proyecto fueron: ¿Cómo manejar la expansión del Área de TI para que brinde soporte al negocio, sin que ello implique duplicar o triplicar el personal actual? ¿Cuáles son los procesos identiﬁcados como críticos? ¿Cómo se los debería medir? ¿Cuáles son las competencias requeridas del equipo de trabajo? ¿Cuál va a ser la organización que soporte dichas competencias? ¿De qué manera la gerencia general puede evaluar el comportamiento del Área de TI respecto del resto del negocio? ¿Cuáles deberían ser los indicadores clave de performance que mostraran objetivamente el comportamiento del área de TI? Desarrollo del caso Como primera medida, el nombrado administrador del proyecto (que a partir de este momento se llamaría AIM-2X) convoca al gerente general y al gerente de tecnologías de información con el objetivo de comenzar con la deﬁnición del alcance del proyecto. En dicha reunión, se comienza a hablar de un rediseño de los procesos y una reorganización de la Gerencia de TI, que tiene como objetivo prepararlos para acompañar un crecimiento en cantidad de puntos de venta, lo que los llevaría a prácticamente triplicar su volumen actual. La idea es pasar de 25 puntos de venta a 75 en el período de cinco años. Metas Las necesidades de la gerencia general se podían resumir en los siguientes puntos: Escalabilidad Cumplimiento Calidad Desarrollar una organización que permita crecer junto con el negocio. Honrar los compromisos como rutina y no como excepción. Esto fue ampliamente apoyado por todos. Incorporar procesos que garanticen la conformidad con la solución ﬁnal obtenida. Costos Motivación Desarrollar la conciencia de costos en el sector de TI. Evitar la rotación del personal de TI; esto sería producto, entre otras razones, de la sobrecarga de trabajo. Mejorar la inserción de la gerencia de TI en el negocio, haciendo visible su Visibilidad performance. (Martinez, 2004, https://www.pmi.org/learning/library/ project-oﬃce-medium-sizedcompanies-1853 ) Análisis del sector de TI encontrado Habiendo el administrador tomado nota de las necesidades que surgieron de la reunión con el gerente general y el gerente de TI, lo primero que hizo fue realizar un pormenorizado análisis del sector de TI y encontró lo siguiente: FO RTA LE Z A S D E BI LI D A D E S / O PO RT U N I D A D E S O BS E RV A C I O N E S A D I C I O N A LE S Un equipo de trabajo integrado que posee un gran sentido de pertenencia a la organización y con un importante conocimiento funcional del negocio. Una edad promedio adecuada para las distintas funciones. Un buen nivel de capacitación, lo cual les da una buena base para planteos futuros (Martinez, 2004). FO RTA LE Z A S D E BI LI D A D E S / O PO RT U N I D A D E S O BS E RV A C I O N E S A D I C I O N A LE S Básicamente expresadas por las necesidades de la gerencia general, las cuales se explicaron en el punto anterior. Organización de TI con problemas de cumplimiento. Baja calidad en sus productos. Muy poca motivación en sus integrantes (Martinez, 2004). El usuario ﬁnal no estaba incorporado al proceso de obtención de soluciones con TI, sino que este esperaba que les fueran provistas. Si eran de su agrado o no, no se tenía en cuenta. El reporte y la resolución de incidentes se efectuaban por varias vías informales y, normalmente, el usuario ﬁnal no era notiﬁcado de las soluciones que se implementaban en respuesta a sus reclamos. FO RTA LE Z A S D E BI LI D A D E S / O PO RT U N I D A D E S O BS E RV A C I O N E S A D I C I O N A LE S La estructura organizativa encontrada era la típica funcional de una Gerencia de TI: un Área de Desarrollo, una de Soporte e Infraestructura y una de Operaciones, cada una con funciones especíﬁcas de cada sector (Martinez, 2004). Figura 2: Organización original del sector Fuente: adaptación propia con base en Martinez, 2004, https://www.pmi.org/learning/library/project-oﬃcemedium-sized-companies-1853 Organización original del sector de TI La organización de TI creció al ritmo del negocio, lo que llevo a que se cubra la demanda de nuevos trabajos y se incorporen recursos, siempre sobre la estructura existente. En el día a día no fue posible analizar la efectividad del proceso aplicado. El método informal de trabajo aplicado no generaba motivación por la indeﬁnición de roles y las responsabilidades que conlleva. Los problemas encontrados dentro de la estructura de TI se podían resumir en: Gran concentración de poder en la Jefatura del Área de Desarrollo. Actitudes heroicas del personal, expresadas fundamentalmente con trabajo adicional o fuera de hora. Atención a usuarios diseminada a lo largo de toda la estructura. No había una única puerta de entrada de reclamos. Diversidad de criterios para planiﬁcar, desarrollar y controlar las actividades, que dependían exclusivamente de la persona responsable. Tareas de soporte y mesas de ayuda que interrumpían las actividades normales de los especialistas, con los problemas que ello acarrea tanto para la persona interrumpida como para el proyecto. Incorporación tardía del desarrollo de las soluciones para los diversos grupos, como Soporte y Operaciones. Carencia de indicadores objetivos de la performance del sector. (Martinez, 2004). Las oportunidades existentes Como indica Martinez (2004): La necesidad de soportar el crecimiento y los diversos inconvenientes percibidos por la empresa y el personal de TI para prestar el servicio requerido permitió, entonces, plantear los siguientes frentes de trabajo: Negocio: mejorar el cumplimiento e integrarse totalmente al negocio. Focalizarse en la gente: aprovechar el capital humano existente y motivarlos con un proyecto desaﬁante. Apuntar a la excelencia: formalizar el concepto de calidad y establecer estándares de excelencia. Estructura organizativa: deﬁnir la estructura con base en los procesos que se deﬁnan y no adecuar los procesos a la estructura. (https://www.pmi.org/learning/library/project-oﬃce-medium-sizedcompanies-1853). Propuesta de solución Se identiﬁcaron los procesos de creación de valor: Figura 3: Procesos de creación de valor Fuente: adaptación propia con base en Martinez, 2004. Atención al negocio: utilización novedosa de TI para el negocio Desarrollo de soluciones: producción de soluciones de negocio Soporte al servicio: provisión de servicios Administración de infraestructura: planiﬁcación y administración de la infraestructura Administración de recursos humanos: adquisición, desarrollo y retención del capital humano Planeamiento estratégico: plan estratégico de TI conjunto con el negocio Administración ﬁnanciera: SLA, seguimiento de costos y benchmarking Administración de relaciones con terceras partes: manejo de expectativas de todos los interesados C O NT I NU A R Lección 2 de 3 La gestión de proyectos en las organizaciones PRE S E N TA C I Ó N D E L C A S O Retomamos el caso de la lectura 1 del módulo 1, en el que —como especialista en sistemas de información— te convocan para asesorar al gobierno en la realización del próximo Censo Nacional. Recuerda que el conocimiento estructurado y formal sobre administración de proyectos y —especíﬁcamente hablando— sobre proyectos de infraestructura de TI no es algo común o que crezca en los árboles. Probablemente tengas que explicar decisiones de proyecto relativas a la infraestructura tecnológica del censo a pares o colegas que tienen formación técnica, pero no de proyectos. Conociendo ya las tendencias en hardware, software y redes (vistas en el módulo anterior), debes decidir como encararás el proyecto de implementación de esta infraestructura, atendiendo a los requerimientos y expectativas del gobierno. La gestión de proyectos en las organizaciones Si se analizan los conceptos de la gestión de proyectos, encontraremos que aparecen deﬁniciones simples, pero importantes que permitirán encontrar el beneﬁcio de tener una infraestructura moderna y adecuada para el negocio de la organización. Por otro lado, el análisis pormenorizado permitirá determinar el verdadero valor que tiene para dicha organización las inversiones que se realicen para tecniﬁcar los procesos de negocios. Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único. Sobre los objetivos de los proyectos, debemos saber que Los proyectos se llevan a cabo para cumplir objetivos mediante la producción de entregables. Un objetivo se deﬁne como una meta hacia la cual se debe dirigir el trabajo, una posición estratégica que se quiere lograr, un ﬁn que se desea alcanzar, un resultado a obtener, un producto a producir o un servicio a prestar. (PMI Santiago de Chile Chapter, 2020, https://www.pmi.cl/pmi/el-producto-o-el-proyecto/). Un entregable se deﬁne como cualquier producto, resultado o capacidad, único y veriﬁcable para ejecutar un servicio, que se produce para completar un proceso, una fase o un proyecto. Los entregables pueden ser tangibles o intangibles. El cumplimiento de los objetivos del proyecto puede producir uno o más de los siguientes entregables: Un producto único, que puede ser un componente de otro elemento, una mejora o corrección de un elemento o un nuevo elemento ﬁnal en sí mismo (por ejemplo, la corrección de un defecto en un elemento ﬁnal). Un servicio único o la capacidad de realizar un servicio (por ejemplo, una función de negocio que brinda apoyo a la producción o distribución). Un resultado único, tal como una conclusión o un documento (por ejemplo, un proyecto de investigación que desarrolla conocimientos que se pueden emplear para determinar si existe una tendencia o si un nuevo proceso beneﬁciará a la sociedad). Una combinación única de uno o más productos, servicios o resultados (por ejemplo, una aplicación de software, su documentación asociada y servicios de asistencia al usuario). Puede haber elementos repetitivos en algunos entregables y actividades del proyecto. Esta repetición no altera las características fundamentales y únicas del trabajo del proyecto. Por ejemplo, los ediﬁcios de oﬁcinas se pueden construir con materiales idénticos o similares, y por el mismo equipo o por equipos diferentes. Sin embargo, cada proyecto de construcción es único en sus características clave (emplazamiento, diseño, entorno, situación, personas involucradas). Los proyectos se llevan a cabo en todos los niveles de una organización. Un proyecto puede involucrar a una única persona o a un grupo; a una única unidad de la organización o a múltiples unidades de múltiples organizaciones. (Poder Judicial de Perú, s. f., https://www.pj.gob.pe/wps/wcm/connect/ugdj/s_ugdj/as_sis gest/as_deﬁnicion/as_proyecto). ¿Puedes armar una tabla con todos los involucrados en lo relativo a la gestión de la infraestructura del proyecto? ¿Qué roles cumplirá cada uno? Los ejemplos más frecuentes de proyectos de infraestructura de TI incluyen, entre otros: La instalación de redes de operadores – Factores como la desregulación del servicio de telecomunicaciones, el avance de Internet y los entornos operativos cada vez más soﬁsticados en las organizaciones actuales se traducen en la necesidad de los operadores de ofrecer un portafolio de servicios cada vez más dinámico. Las redes son cada vez más soﬁsticadas y conforman verdaderas plataformas multimediales capaces de ofrecer cada vez más y mejores servicios, en las que prevalecen las conexiones de datos de alta velocidad. Nada de esto es posible sin las estructuras troncales de transmisión de paquetes de alta capacidad, capaces de absorber las altas demandas de tráﬁco por parte de los usuarios. Hoy todo el mundo quiere y necesita estar conectado y para ello los operadores necesitan desarrollar redes de alta capacidad. Además de la infraestructura necesaria en redes de transporte, también es necesario desarrollar conmutadores WAN multiprotocolos, redes de acceso alámbricas e inalámbricas (antenas) de altas prestaciones que permitan el acceso a los servicios ofrecidos. Los operadores, por su parte, cada vez dan más valor a la calidad de las relaciones con sus clientes. Hoy lo que hace la diferencia entre competidores no son los productos que se ofrecen, sino la forma de construir relaciones duraderas con los clientes. La instalación de redes corporativas – Una red corporativa proporciona un medio para distribuir información. Sin una red corporativa ﬁable, la información que se genera en los entornos corporativos carece de valor, pues no se encuentra disponible para el usuario que verdaderamente la necesita. Básicamente los proyectos de redes corporativas son capaces de interconectar los ediﬁcios centrales de las organizaciones con sus ﬁliales. Este es un ejemplo típico y muy frecuentemente usado en la actualidad. Las dos corrientes con mayor crecimiento en redes corporativas son sin dudas las redes basadas en protocolos IP (Internet) y redes de área local inalámbricas. La integración de soluciones de seguridad – El avance de Internet trae aparejado muchos problemas con la seguridad. Son innumerables los casos de empresas que sufrieron ataques maliciosos y vieron afectada su capacidad operativa. Esto no hace más que reaﬁrmar la importancia que tiene trabajar en proyectos de seguridad que proporcionen a las organizaciones un entorno sin problemas, para proteger, de esta manera, los activos de la compañía. Los proyectos de desarrollo en sistemas de seguridad con sistemas adaptables a las necesidades de los modelos de cada empresa son: La integración segura a Internet: Como primera opción de seguridad aparecen los denominados cortafuegos (ﬁrewall en inglés) que son una parte de un sistema o una red que está diseñada para bloquear el acceso a usuarios no autorizados. Se trata de un dispositivo o conjunto de dispositivos conﬁgurados para permitir, limitar, cifrar y descifrar el tráﬁco entre los diferentes ámbitos sobre la base de un conjunto de normas y otros criterios deﬁnidos por cada operación. Una adecuada conﬁguración del ﬁrewall —para solo permitir el acceso a usuarios autorizados— debe complementarse con programas que protejan la información contra un virus o la manipulación de servidores malintencionada por parte de usuarios autorizados. Los dispositivos que permiten detectar los accesos maliciosos están permanentemente analizando el tráﬁco que atraviesa la red y buscando patrones de ataque, los cuales, cuando son detectados, generan alarmas e informan al ﬁrewall para que baje la conexión maliciosa. Redes privadas virtuales: a través de las redes privadas (VPN) los usuarios móviles o teletrabajadores pueden acceder a los recursos de sus respectivas empresas sin comprometer la conﬁdencialidad de la información que manejan. Un complemento al acceso de VPN son los token o dispositivos que generan una clave cada vez que un usuario quiere ingresar a la red. La instalación de infraestructura de telecomunicaciones en ediﬁcios y oﬁcinas: La instalación de infraestructura en el interior de ediﬁcios de oﬁcina y/o habitaciones supone un avance importante para el acceso a las nuevas tecnologías. Estas instalaciones en muchos países están totalmente reguladas por los entes de gobierno. En cuanto al tiempo deﬁnido para cada proyecto: La naturaleza temporal de los proyectos implica que un proyecto tiene un principio y un ﬁnal deﬁnidos. Que sea temporal no signiﬁca necesariamente que un proyecto sea de corta duración. El ﬁnal del proyecto se alcanza cuando se cumplen una o más de las siguientes situaciones: Los objetivos del proyecto se han logrado. Los objetivos no se cumplirán o no pueden cumplirse. El ﬁnanciamiento del proyecto se ha agotado o ya no está disponible. La necesidad del proyecto ya no existe (por ejemplo, el cliente ya no desea terminar el proyecto; un cambio de estrategia o prioridad pone ﬁn al proyecto; la dirección de la organización decide ﬁnalizar el proyecto; etc.). Los recursos humanos o físicos ya no están disponibles. El proyecto se da por terminado por conveniencia o causa legal. Los proyectos son temporales, pero sus entregables pueden existir más allá del ﬁnal del proyecto. Los proyectos pueden producir entregables de naturaleza social, económica, material o ambiental. Por ejemplo, un proyecto para construir un monumento nacional creará un entregable que se espera perdure durante siglos. Los proyectos impulsan el cambio en las organizaciones. Desde una perspectiva de negocio, un proyecto está destinado a mover una organización de un estado a otro estado, a ﬁn de lograr un objetivo especíﬁco. Antes de que comience el proyecto, normalmente se dice que la organización está en estado actual. El resultado deseado del cambio impulsado por el proyecto se describe como el estado futuro. Para algunos proyectos, esto puede implicar la creación de un estado de transición, en el cual se llevan a cabo múltiples pasos para alcanzar el estado futuro. La conclusión exitosa de un proyecto conduce a que la organización pase al estado futuro y alcance el objetivo especíﬁco. (Seunpmp, 2020, https://seunpmp.wordpress.com/2020/05/11/que-es-unproyecto/). ¿Tienes claro cuál será el ﬁnal del censo? ¿Qué hito o entregable se alcanzará? ¿Qué me dirá a mí que el proyecto ha terminado? ¿Cuál es el estado actual y el estado futuro de la información del censo? La triple restricción Veamos cuales son las restricciones a tener en cuenta en un proyecto: En un proyecto existen muchas restricciones, pero hay tres que se consideran especialmente importantes y que son comunes a todos los proyectos: el costo, el alcance y el tiempo (plazo). Para referirse a estas tres restricciones y su interacción a lo largo del proyecto, se utiliza el término triple restricción. Tiempo: todos los proyectos vienen delimitados por el tiempo, siempre hay una fecha que cumplir. Costo: esta variable no solo incluye el dinero, sino todos los recursos que se necesitan para llevar a cabo el proyecto; tales como: personas, equipamientos, materiales, etc. Alcance: cada proyecto produce un único producto (bien o servicio), el alcance del proyecto describe y limita el trabajo requerido para conseguir el producto. (Eduocastella, http://blog.masterinprojectmanagement.net/page/11/). Figura 1: La triple restricción 2013, Fuente: Fanjul, 2018, http://www.rnds.com.ar/articulos/117/RNDS_114-116W.pdf Sin embargo, los modelos actuales consideran que los proyectos se enfrentan no solo la triple restricción —alcance, costo y tiempo—, sino que ahora esta se extiende a más dimensiones. Figura 2: La triple restricción extendida Fuente: Josafat Gascon Busio, s.f., https://todopmp.com/la-famosa-triple-restriccion/ Ciclo de vida del proyecto Es una serie de fases por las que atraviesa un proyecto desde su inicio hasta su cierre. Estas son generalmente secuenciales, se dividen por objetivos, son acotadas en el tiempo y describen qué se necesita hacer para completar el trabajo. Los proyectos varían en tamaño y complejidad, pero básicamente tienen etapas de inicio, de preparación, de ejecución y de cierre. Habitualmente, el grueso de los tiempos y los recursos son destinados a las fases de ejecución de un proyecto. También es común que las tareas de PM o DP sean más importantes durante las fases constructivas del proyecto. Las tendencias más modernas proponen transferir parte de estas tareas a las fases más creativas o de planiﬁcación del proyecto. Figura 3: El ciclo de vida de los proyectos Fuente: Josafat Gascon Busio, s.f., https://todopmp.com/la-famosa-triple-restriccion/ La documentación del proyecto En un sentido amplio, un documento es una carta o un escrito que acredita un hecho, situación o circunstancia. Puede decirse, además, que un documento proporciona datos para ser utilizados con el objetivo de comprobar un hecho. Muchas son las clasiﬁcaciones que se realizan de los diferentes tipos de documentos. Básicamente, se establecen dos grandes grupos: documentos textuales (aquellos que se realizan sobre papel) y documentos no textuales (se confeccionan o almacenan sobre cualquier soporte que no sea el papel) Como ejemplo de esto último están aquellos documentos que se guardan en medios magnéticos; como discos rígidos, discos compactos, DVD o pen drive. No obstante, existe otra clasiﬁcación según la información que contienen. Así, se describen los documentos primarios, que son los transmiten directamente la opinión de quien los realiza; los secundarios, que son el resultado de haber analizado los archivos primarios; y los terciarios, que surgen del tratamiento hecho de los documentos secundarios. Otra clasiﬁcación que se puede dar es según el ámbito de aplicación, sea público o privado. Un documento es un escrito que acredita algo y todo documento puede incluir todos o algunas de las siguientes características: Haber sido confeccionado para ser una directiva, orden o instrucción. Haber sido confeccionado para servir de aviso o consejo. Haber sido confeccionado para ilustrar o comprobar. Convertirse en una prueba para quienes lo escriben o suscriben. Servir para acreditar hechos y su fecha. Documentos de proyectos: los clásicos Desde un punto de vista denominado clásico, se considera que el proyecto tiene una serie de documentos que van a permitir materializar una idea dentro de un tiempo preestablecido y con un costo determinado. No existen los proyectos con tiempos de ejecución inﬁnitos o sin una limitación en cuanto a los costos, consecuentemente, un proyecto siempre viene de la mano de un cronograma y un costo asociado. Más especíﬁcamente, los documentos van a deﬁnir qué se espera, las instalaciones a llevar a cabo, los trabajos correspondientes, la forma en que se van a encarar dichos trabajos, quién será responsable de qué, etc. La sumatoria de documentos permitirá que cualquier técnico especializado pueda desarrollar, coordinar y supervisar la ejecución de un proyecto, cualquiera sea el objetivo que persiga y a pesar de no haber sido el autor de este. De la deﬁnición misma surgen algunos conceptos importantes: el primero es que un proyecto contiene una serie de documentos que van a ayudar a hacerlo realidad; el segundo es que estos documentos necesariamente tienen que ser entendibles o interpretables por otras personas además de quienes lo concibieron. Como se dijo más arriba cuatro son los documentos básicos de un proyecto (también denominados clásicos). Estos son: La declaración del proyecto (statement of work) – Documento que describe el proyecto desde su concepción y su objetivo hasta el estudio de las necesidades que debe cubrir, expresado en forma descriptiva. En la memoria se podrían encontrar gráﬁcos, diagramas, dibujos o croquis que contribuyan a una mejor descripción del objetivo perseguido y las soluciones propuestas. También se detallan los acuerdos y presuposiciones. Los planos o planes – Constituyen la representación gráﬁca del proyecto. No existe un número o cantidad especíﬁca de planos, sino que deberán incluirse todos aquellos que fueran necesarios para garantizar su correcta ejecución. Incluyen diagramas de tiempo, de espacio físico o geográﬁco, de relaciones o jerarquías, etc. El pliego de condiciones – Se denomina pliego de condiciones al documento contractual, de carácter detallado y obligatorio, en el cual se establecen las condiciones o cláusulas que se aceptan en un contrato de obras o servicios. Dentro de un pliego de condiciones se indica cómo y con qué hay que hacer realidad las tareas que van a formar parte del proyecto y que se llegaran a contratar. En el pliego que se acuerda y ﬁrma, se encuentran expresamente determinadas las relaciones que existirán y que tienen que cumplirse entre quien contrata la ejecución del proyecto y su ejecutor. La memoria técnica – Este documento debe contener toda la información técnica necesaria para que el proyecto llegue a buen ﬁn de acuerdo con los planos constructivos de este. Por lo que debe indicar las condiciones generales del trabajo, la descripción y características de los materiales a utilizar, las normas de referencia, los planos constructivos y la localización de las tareas. También señala los derechos, obligaciones y responsabilidades de las partes que lo suscriben. El presupuesto – Es una previsión del costo que va a tener la ejecución del proyecto y puede estar compuesto por uno o varios presupuestos parciales, además de los ﬂujos de caja previstos y los cuadros de resultados esperados y actuales. ¿Cuál crees que será la ﬁnalidad de tener estos documentos para el Censo Nacional? ¿Cuáles otros documentos entiendes que serán necesarios? Documentos de proyectos: otros documentos Existen, además de los documentos clásicos, los denominados otros documentos; algunos de los cuales no tienen igual importancia que aquellos y otros que son complementarios. Algunos de estos documentos —solo los vamos a mencionar, dado que no son el objeto de nuestro estudio— pueden los siguientes: documentos de dirección, documentos de planiﬁcación y control, documentos de coordinación, documentos de ingeniería de proceso, documentos relativos a los costos unitarios y ﬂujos de caja, instructivos de montajes y muchos otros. En conclusión, y para cerrar el tema de los documentos en los proyectos, se puede decir que son escritos que sirven para desarrollar y ejecutar un proyecto o para servir de evidencia respecto a decisiones o acuerdos tomados durante el transcurso del proyecto y que afectan al estado futuro de este. En el siguiente bloque podrás leer un caso sobre operación orientada a proyectos. C O NT I NU A R Lección 3 de 3 Referencias Bowlby, C. (30 de junio de 2019). Berlín Brandenburg: el aeropuerto con medio millón de fallas que contradice la imagen de eﬁciencia de Alemania. BBC News [versión digital]. Recuperado de https://www.bbc.com/mundo/noticias-48814654 Eduocastella. (12 de diciembre de 2013). Triple restricción [Publicación en el blog de LS BESBNC]. Recuperado de http://blog.masterinprojectmanagement.net/page/11/ Fanjul, J. (2018). ¿Qué es la triple restricción en el diseño de un proyecto?. Revista Negocios de Seguridad, (117), pp. 114-116. Recuperado de http://www.rnds.com.ar/articulos/117/RNDS_114-116W.pdf Josafat Gascón Busio, O. (s. f.). La famosa triple restricción [Publicación en el blog de Todo PMP]. Recuperado de https://todopmp.com/la-famosa-triplerestriccion/ Martinez, R. (2004). La oﬁcina de proyectos en empresas medianas. Un caso práctico. Paper presentado en el encuentro PMI Global Congress Proceeding, Buenos Aires. Recuperado de https://www.pmi.org/learning/library/projectoﬃce-medium-sized-companies-1853 PMI Santiago de Chile Chapter. (2 de julio de 2020). ¿El producto o el proyecto? [Publicación en el blog PMI]. Recuperado de https://www.pmi.cl/pmi/el-producto-o-el-proyecto/ Poder Judicial de Perú. (s. f.). Proyecto. [Publicación en el blog del Poder Judicial de Perú]. Recuperado de https://www.pj.gob.pe/wps/wcm/connect/ugdj/s_ugdj/as_sisgest/as_deﬁnic ion/as_proyecto Seunpmp. (11 de mayo de 2020). ¿Qué es un proyecto? [Publicación en blog Se un PMP Proyect Manager Professional Certiﬁcado]. Recuperado de https://seunpmp.wordpress.com/2020/05/11/que-es-un-proyecto/ Proyectos de tecnologías de la información No hubo otra cosa que los pilotos pudieran hacer. Mientras las alarmas sonaban dentro de la cabina, el capitán y el primer oﬁcial luchaban por recuperar el control de la aeronave. Estaban demasiado cerca del suelo y necesitaban con urgencia ganar altura nuevamente. Pero cuando el capitán Yared Getachew intentaba orientar la trompa del Boeing 737 Max 8 hacia arriba, el sistema electrónico del avión la forzaba hacia abajo. Quedaba claro que empujar de nuevo los controles no sería suﬁciente. Entonces, hundió un botón para ajustar el balance aerodinámico de la aeronave y, de esa manera, obligarla a que subiera. Pero, solo unos segundos después, esos ajustes se revirtieron automáticamente. Los intentos no terminaron allí: probaron los controles manuales y otra vez estos se revirtieron a los sistemas de vuelo automático, mientras sonaba una alarma a intervalos cada vez más cortos para señalar que la velocidad se incrementaba peligrosamente. Tanto Getachew como el primer oﬁcial Ahmednur Mohammed Omar lo intentaron todo. Pero, ﬁnalmente, el vuelo 302 de Ethiopian Airlines, que se dirigía el pasado 10 de marzo desde la capital etíope Addis Ababa hacia Nairobi (Kenia), se estrelló contra el suelo a 500 kilómetros por hora a solo seis minutos de despegar y con 157 personas a bordo. Era un avión nuevo y contaba con condiciones óptimas: buena visibilidad, un cielo despejado y libre de vientos siniestros. Entre las víctimas había ciudadanos de 35 países, entre ellos, el vicedirector de comunicaciones de UNESCO y el ex diplomático nigeriano Abiodun Bashua, además de tres generaciones de una misma familia canadiense. Los pilotos del avión de Ethiopian Airlines accidentado siguieron repetidamente las recomendaciones de Boeing, pero no funcionaron. ¿Cómo pudo afectar que el avión fuera nuevo en el accidente de Lion Air en Indonesia? Cinco meses antes, en un avión casi idéntico y operado por la aerolínea indonesia Lion Air, ocurrió un episodio trágicamente similar: pocos minutos después de despegar, los pilotos tuvieron una seguidilla de problemas para controlar la aeronave. El vuelo, que iba a durar poco más de una hora, había salido del aeropuerto internacional de Jakarta y se dirigía a la ciudad de Pangkal Pinang, en el oeste de Indonesia. Cada vez que intentaban levantar la trompa, los esfuerzos de los pilotos se revertían segundos más tarde, ya que los sistemas automáticos forzaban nuevamente a la nave hacia abajo. Después de una veintena de intentos por estabilizar el Boeing 737 Max 8 sin éxito, este cayó al mar de Java. Esa vez murieron 189 personas. Dos accidentes fatales muy similares con solo cinco meses de diferencia y con aeronaves de la misma marca y del mismo nuevo diseño. Pocos días después del accidente de Etiophian Airlines, los investigadores notaron similitudes claras entre ambos siniestros. Entonces, ¿hay una causa común a los dos accidentes? En el caso del vuelo de Lion Air, la caja negra fue recuperada del fondo del mar a los pocos días y, efectivamente, otorgó información vital sobre los últimos minutos del vuelo. De allí surgieron los primeros indicios sobre lo que había salido mal: los investigadores se enfocaron en el software que controlaba el vuelo y que estaba diseñado para operar en segundo plano, sin que siquiera el piloto sepa que estaba en funcionamiento. Boeing ideó este programa para resolver la tendencia de la nariz del Boeing 737 Max a elevarse más de lo necesario, especialmente cuando está en un ángulo pronunciado. Pero, aparentemente, se activó en el momento equivocado. Así, forzó a la trompa a "tirar" hacia abajo en el preciso momento en que debería haber ido hacia arriba, durante el despegue. Asimismo, los estabilizadores —las pequeñas alas que van a los lados de la cola— fueron colocados en una posición errónea por el computador del avión. Y cuando los pilotos trataron de corregirlo, el software anuló esa orden y los llevó otra vez a la posición inicial. (Leggett, 2019, https://www.bbc.com/mundo/noticias-internacional-48475878). Proyectos de tecnologías de la información Referencias Descarga en PDF Lección 1 de 3 Proyectos de tecnologías de la información Proyectos de tecnologías de la información PRE S E N TA C I Ó N D E L C A S O Retomamos el caso de la lectura 2 del módulo 1, en el que —como gerente de TI de una empresa metalmecánica mediana— te has visto sobrepasado con las demandas de tus pares gerentes de otras áreas, quienes, constantemente, solicitan mejoras o parches al sistema para no tener que depender de aplicaciones comerciales que no se adaptan del todo a la operatividad de la empresa. Situémonos en el área comercial de la compañía, donde se manejan normalmente más de 100 clientes de distintos rubros y tamaños, cada uno con una condición comercial especial y una logística de entregas particular. La empresa ofrece una variedad de más de 200 productos estándar y también produce a pedido algunos productos especiales, que requieren un diseño. Este diseño puede ser del propio cliente o puede requerir de nuestra ingeniería para desarrollarlo; en cuyo caso, la ingeniería del producto se vuelve un producto más. Como señala Annan (2003): Las tecnologías de la información y la comunicación (TIC), son conceptos muy asociados al de informática, si se entiende esta última como el conjunto de recursos, procedimientos y técnicas usadas en el procesamiento, almacenamiento y transmisión de información. Esta deﬁnición se ha matizado de la mano de las TIC, pues en la actualidad no basta con hablar de una computadora cuando se hace referencia al procesamiento de la información. (Annan, 2003, http://tecnomontelibano.blogspot.com/2014/02/tecnologias-dela-informacion-y-la.html). Como vimos en la lectura de la introducción, los dispositivos e infraestructura de las TIC pueden ser tan diversos como una PC doméstica o un avión de última generación. Tal como se ha dicho arriba, en más de una ocasión un proyecto se conforma de una serie de actividades que, realizadas en forma organizada, apuntan a resolver una necesidad. Un proyecto de tecnologías de la información intentará lograr los objetivos por medio de la implementación de las tecnologías de la información, pero estas no son un ﬁn en sí mismo, sino un medio para alcanzar otros objetivos preﬁjados por una organización. Un proyecto insume todo tipo de recursos, entre los cuales podrían considerarse aquellos que se relacionan con los equipos de trabajo competentes, el equipamiento tanto de hardware como de software, el espacio físico, la energía, los recursos ﬁnancieros, entre otros. La administración adecuada de todos estos recursos es lo que permitirá el logro de los objetivos propuestos y el cumplimiento con el presupuesto acordado dentro de los plazos estipulados con anterioridad. Por otro lado, cada proyecto tiene asociada una cuota de riesgo e incertidumbre. Solo un estricto planeamiento y control permitirá reducir al mínimo la cuota de riesgo y aumentar los márgenes de certeza. Estos son algunos de los criterios que permiten agrupar o clasiﬁcar a los proyectos de tecnología de la información: Figura 1: Clasiﬁcación de proyectos Fuente: adaptación propia con base en Chinkes y Oriolo, 2004. ¿Cómo clasiﬁcarías el proyecto cuyo objetivo es dotar a la organización de una base de datos común para la gestión comercial, administrativa, técnica, etc.? Rápidamente, veamos esta clasiﬁcación: Según el área funcional a la cual brindan soporte: un proyecto de TI puede abarcar un área especíﬁca o puede ser abarcativa de distintas áreas. Un proyecto de TI no tiene un ﬁn en sí mismo, sino que las tecnologías de la información proporcionan un medio para alcanzar otros ﬁnes, por lo cual es natural la concurrencia de varias áreas. Según el alcance: Un proyecto de TI puede tener distintos alcances y esta amplitud marca,} de alguna manera sus límites. Un proyecto puede tener por ﬁnalidad corregir, mejorar o adaptar una aplicación nueva o existente. No existe un alcance único, sino que los alcances varían de proyecto a proyecto. Según la arquitectura tecnológica: un cambio en la arquitectura de un sistema de información puede deﬁnir una distinta forma de operar. Por ejemplo, un proyecto puede desarrollarse en entornos que están basados en mainframe, en entornos Windows o, incluso, existen algunos que no están basados en computadores. Todos son proyectos de sistemas de tecnologías de información, solo la forma para encararlos en términos tecnológicos es diferente. Según si se construye o se compra: un proyecto de TI puede considerar la compra a medida, la compra de un producto enlatado o la compra de los componentes de manera separada para que luego puedan ser ensamblados por un equipo de trabajo. Los tres modelos son ampliamente utilizados por las organizaciones y la elección depende de muchos factores. Algunos de estos factores son el costo de los insumos, el costo de la mano de obra, la necesidad de integración del nuevo sistema a las aplicaciones existentes, etc. Según el tamaño o multiplicidad: un proyecto puede dividirse debido a su gran tamaño o bien puede contener otros proyectos. Cuando se produce la multiplicidad de proyectos hay que tener en cuenta la interdependencia que existe entre los recursos utilizados, la plataforma, los hitos y los equipos de trabajo. Alineación entre los proyectos de TI y el negocio El llamado plan de sistemas de información es un documento de la organización que se apoya en el plan de negocios general y en el que se incorporan los sistemas estratégicos a la planeación de nivel superior. El motivo base de este documento es dar directrices para el desarrollo de sistemas y su fundamento, la situación actual de sistemas, los nuevos desarrollos a tener en cuenta, la estrategia gerencial, el plan de implementación y el presupuesto. El plan indica las decisiones gerenciales claves en relación con la adquisición de hardware, las telecomunicaciones, la centralización/descentralización de la autoridad, los datos y el hardware, además del cambio organizacional requerido. Por lo general, también se describen los cambios organizacionales, como los requerimientos de capacitación para gerentes y empleados, los esfuerzos de reclutamiento, los cambios en los procesos de negocios, en la autoridad, en la estructura o en la práctica gerencial. (Laudon y Laudon, 2012, 17). ¿Puedes hacer un esbozo del plan de sistemas de la metalmecánica y comprobar si está alineado con el plan de negocios de la empresa? Para responder esta pregunta, te proponemos a continuación un modelo de plan de sistemas de una empresa “X”, solo a los ﬁnes de ejempliﬁcar el plan. Figura 2: Plan estratégico de sistemas TIC Fuente: [Imagen sin título sobre planes de sistemas de la información]. (s. f.). Recuperado de https://lh3.googleusercontent.com/93v5tmivYlztCBQrefMSJBBWtnwA3MADqP2a4oBAxwad0 3SHuxlLQkjbW_60LNs4ubcm5Q=s151 1. Deﬁnir objetivos, organización, ámbito y plan del proyecto – Especiﬁcación de objetivos Identiﬁcación de las unidades afectadas Organización de los participantes Planiﬁcación del proyecto 2. Identiﬁcar necesidades de información – Identiﬁcación de funciones y objetivos Identiﬁcación de requisitos Identiﬁcación de necesidades de información 3. Identiﬁcar directrices de gestión y directrices técnicas Identiﬁcar directrices de gestión Identiﬁcar directrices técnicas – 4. Diseñar arquitectura de información – Diseño de modelo conceptual de datos Diseño de jerarquía de funciones Diseño de arquitectura de la información 5. Revisar situación actual del sistema informático – Identiﬁcación y descripción de sistemas existentes Análisis del entorno tecnológico actual Diagnóstico de la situación actual 6. Especiﬁcar nuevos sistemas Identiﬁcar mejoras en sistemas actuales Identiﬁcar nuevos sistemas Determinación de prioridades Especiﬁcación de sistemas 7. Deﬁnir las alternativas tecnológicas – – Identiﬁcación de necesidades tecnológicas futuras Deﬁnición de opciones tecnológicas – 8. Elaboración del plan de acción Elaboración del plan de implantación Mantenimiento del plan de sistemas El proyecto debe estar alineado al negocio y debe ser el foco rector que guíe las decisiones que el administrador tome durante el proyecto para lograr una administración exitosa. Este aspecto debe ser considerado por el administrador durante toda la extensión del proyecto, aunque se evidenciará más claramente en la etapa de planiﬁcación, cuando se analizan, entre otras cosas, la contribución estratégica y su factibilidad económica y ﬁnanciera. C O NT I NU A R Lección 2 de 3 Referencias Annan, K. (2003). Discurso inaugural de la primera fase de la Cumbre Mundial sobre la Sociedad de la Información (Discurso inaugural). Recuperado del sitio de Internet Tecno Montelíbano: http://tecnomontelibano.blogspot.com/2014/02/tecnologias-de-lainformacion-y-la.html Chinkes E. y Oriolo C. (2004). Administración de proyectos de tecnología de la información. Buenos Aires, AR: Cooperativas. Laudon, K y Laudon, J. (2012). Capítulo 14: Administración de proyectos. En Autor, Sistemas de información gerencial administración de la empresa digital. Naucalpan de Juárez, MX: Pearson Educación. Legget, T. (8 de junio de 2019). Boeing 737 Max: ¿qué ocurrió dentro de la cabina de los aviones que se accidentaron en Etiopía e Indonesia?. BBC News [versión digital]. Recuperado de https://www.bbc.com/mundo/noticiasinternacional-48475878 [Imagen sin título sobre planes de sistemas de la información]. (s. f.). Recuperado de https://lh3.googleusercontent.com/93v5tmivYlztCBQrefMSJBBWtnwA3MAD qP2a4oBAxwad03SHuxlLQkjbW_60LNs4ubcm5Q=s151 Lección 3 de 3 Descarga en PDF Módulo 3 - Lectura 2.pdf 441.8 KB Administración del proyecto, el riesgo, el costo y el tiempo El desafío más imperioso y urgente al que se enfrenta el NHS (National Health System) de Inglaterra es que, con frecuencia, se requiere mucho tiempo de espera para recibir atención, lo que algunas veces puede producir consecuencias nefastas. El servicio médico para todos sin importar el nivel económico es un valor básico de la sociedad británica. Un estudio del Commonwealth Fund en 2013 sobre los sistemas nacionales de servicios médicos caliﬁcó al NHS en primer lugar en calidad de atención, seguridad, coordinación de la atención, atención centrada en el paciente y costo. En cuanto a la puntualidad de la atención, el Reino Unido se clasiﬁcó en tercer lugar. Dado que la puntualidad de la atención es el objetivo primordial, el NHS de Inglaterra lanzó el servicio e-Referral a ﬁnales de 2014. La directora de sistemas estratégicos y tecnología, Beverly Bryant, espera una reducción considerable en el papeleo y de errores en los datos, junto con un proceso de referencias acelerado, ya que los pacientes monitorean y administran sus propias citas de hospital. Se están explorando varias ideas para fomentar la adopción de este servicio, incluyendo hacer que la participación de los médicos sea obligatoria y desarrollar un programa de incentivos que incorpore castigos, así como recompensas. El objetivo es mejorar —o eliminar— las fallas de Choose and Book; a partir de, por ejemplo, alejarse del entorno híbrido entre el soporte electrónico y el papel, que ha demostrado ser una carga para los hospitales. El cambio a solo digital ocurrirá para 2019. El nuevo sistema usa una plataforma abierta y un conjunto de interfaces de programación de aplicaciones (API); ambos elementos ofrecen una mayor ﬂexibilidad de integración con otros sistemas en comparación con el sistema propietario restrictivo empleado por Choose and Book. Más aún, estos cambios deben reducir los costos de operación. Después de una década de avances tecnológicos, las actualizaciones habrían sido necesarias, incluso aunque Choose and Book hubiera sido un éxito rotundo. El nuevo sistema e-Referrals debe superar el récord de Choose and Book de reservar 40 000 citas a diario, asegurar que todos los espacios para las citas estén disponibles y transportar a los ciudadanos a sus citas a un ritmo más rápido, al mismo tiempo que debe conseguir que no empeoren las desigualdades existentes en el servicio de atención médica. Administración del proyecto, el riesgo, el costo y el tiempo Referencias Descarga en PDF Lección 1 de 3 Administración del proyecto, el riesgo, el costo y el tiempo PRE S E N TA C I Ó N D E L C A S O Retomamos el caso de la lectura 3 del módulo 1, en el cual eres es el nuevo gerente de TI de la tarjeta de crédito Cobrex y, en tu primera reunión de staff, el CEO de la compañía comenta que si bien los números de la compañía están en verde, no están consiguiendo los objetivos planteados por los accionistas. Empiezas a pensar en el proyecto de dotar de tecnología tipo contactless a la red de comercios que usan la tarjeta Cobrex. Para esto, debes tener en cuenta los costos y los plazos que se han propuesto y, sobre todo, los riesgos que signiﬁca cambiar algo que anda bien —la tecnología actual— por algo novedoso y en desarrollo —el contactless—. La primera idea es tomar el proyecto directamente en tus manos, pero necesitas actualizarte en project management y entender todo lo que esto involucra. Administración del proyecto ¿Qué es el project management? La deﬁnición clásica del Project Management Institute (2017) —PMI de ahora en adelante— lo caracteriza como la “aplicación de conocimiento, aptitudes, herramientas y técnicas a las actividades del proyecto, las cuales deben estar encaminadas a satisfacer o colmar las necesidades y expectativas de las entidades y organizaciones involucradas en un proyecto”. Hay que diferenciar entre la gestión y la dirección de proyectos. Nuevamente aquí, el PMI (2017) establece las siguientes diferencias entre ambas: G E STIÓN D I RE C C I Ó N Tareas de planiﬁcación, seguimiento y control de un proyecto. Empleo de recursos y costes; y organización. G E STIÓN D I RE C C I Ó N Tareas de organización de un proyecto. Tareas de organización de la empresa y el equipo de proyectos. Coordinación, liderazgo y responsabilidad. Cada proyecto es único y, por ende, deberá llevarse a cabo teniendo cuenta sus particularidades, que dependerán, entre otros factores, del área involucrada, la infraestructura, el poder existente en la organización, la cultura organizacional, los tiempos asociados, el equipo de trabajo, la tecnología elegida, los estándares de calidad y las metodologías empleadas para llevar a cabo los planes de trabajo. Estos son solo algunos factores, pero no los únicos, que hacen que un proyecto se distinga de todos los demás. Sin embargo, hay actividades que el administrador deberá contemplar para todos los proyectos, a saber: Qué debe hacerse, cuándo, cómo y con qué recursos. Confeccionar el plan de trabajo. Organizar y supervisar el equipo de trabajo. Asegurar los recursos necesarios para que las tareas puedan llevarse a cabo. Optimizar el uso de los recursos destinados al proyecto. Evaluar y coordinar los cambios. Asegurar los estándares de calidad. Minimizar los riesgos. Controlar el grado de avance. Informar a toda la organización de los avances y desvíos, si los hubiera. En la deﬁnición utilizada por las guías para la gestión de proyectos según Project Management Institute existen procesos, grupos de procesos (o fases) y áreas de conocimiento. La salida de un proceso, por lo general, se convierte en una entrada a otro proceso o es un producto entregable del proyecto. Áreas de conocimiento y grupos de procesos Figura 1: Grupos de procesos y áreas de conocimiento del Project Management Body of Knowledge (PMBOK) Fuente: [Imagen sin título sobre grupos de procesos y areas de conocimiento]. (s. f.). Recuperado de https://wolfproject.es/curso/dinamica-procesos-pmbok-6-2017/ ¿Tienes claro qué procesos se aplicarán en el proyecto de implementación de la tecnología contactless y cuáles no? Por ejemplo, si todo el desarrollo será hecho internamente, no tendrás proceso de adquisiciones. Es necesario destacar que los grupos de procesos se superponen a lo largo del proyecto en, prácticamente, todas las fases y áreas de conocimiento. No son compartimentos ni deben serlo. El ser riguroso en la aplicación de la metodología no implica rigidez ni inﬂexibilidad para la ejecución. Las distintas interacciones entre procesos, en función de la escala temporal de un proyecto genérico, puede graﬁcarse como sigue: Figura 2: Interacciones de grupos de proceso a lo largo del proyecto Fuente: [Imagen sin título sobre interacciones de grupos de proceso a lo largo del trayecto]. (s. f.). Recuperado de https://wolfproject.es/curso/dinamica-procesos-pmbok-6-2017/ Pero, ¿de qué trata cada uno de ellos? Veamos las siguientes actividades: Gestión de la integración: identiﬁcar, deﬁnir, combinar, uniﬁcar y coordinar los distintos procesos y actividades del proyecto. Gestión del alcance: asegurar que el proyecto incluye todos los trabajos requeridos, y solo estos. ¿Qué está incluido y qué no en el proyecto? Gestión del tiempo: asegurar la realización del proyecto dentro de los plazos. Gestión de los costos: asegurar que el proyecto se complete dentro del presupuesto previsto. Gestión de la calidad: determinar las políticas, los objetivos y las responsabilidades relativos a la calidad, de modo que el proyecto satisfaga las necesidades por las cuales se emprendió. Gestión de los recursos: conseguir la máxima efectividad de las personas y los recursos físicos del proyecto (en versiones anteriores se le ha denominado gestión de los recursos humanos). Gestión de las comunicaciones: asegurar, en el tiempo y forma adecuados, la generación, recopilación, diseminación, almacenamiento y localización ﬁnal de la información del proyecto. Gestión de los riesgos: identiﬁcar, analizar y dar respuesta a los riesgos del proyecto; maximizar la probabilidad y las consecuencias de eventos positivos y minimizar las de eventos negativos. Gestión de las adquisiciones: adquirir productos (bienes y/o servicios) fuera de la organización que realiza el proyecto. Gestión de los interesados/agentes (stakeholders): conseguir la satisfacción de los stakeholders del proyecto. Administración del riesgo Un riesgo es todo evento o condición incierta que, en caso de darse, tendrá un efecto positivo o negativo sobre los objetivos de un proyecto. Algunas características del riesgo son: Tiene una o más causas y, en el caso de darse, uno o más impactos (efectos). Los riesgos conocidos son aquellos que han sido identiﬁcados y analizados durante la planiﬁcación del proyecto. Es importante notar que existen riesgos con efectos positivos. A estos los denominamos oportunidades, por ello la gestión de riesgos puede deﬁnirse así: Es identiﬁcar, analizar y dar respuesta a los riesgos del proyecto, maximizando la probabilidad y las consecuencias de eventos positivos y minimizando la probabilidad y las consecuencias de eventos negativos. Existen hoy muchas técnicas de identiﬁcación de riesgos y hasta una norma que deﬁne los requisitos que se deben implementar para tener un sistema formal de gestión de riesgos en una organización (ISO 310001). Algunas de las técnicas más conocidas son: ISO 31000. (2008). Gestión de Riesgo y Directrices. Organización Internacional de Normalización. Recuperada de https://www.iso.org/obp/ui#iso:std:iso:31000:ed-2:v1:es AMFE (Análisis del Modo de Fallas y sus Efectos) FODA (Fortalezas, Oportunidades, Debilidades y Amenazas) PESTEL (Análisis de Contexto Político, Económico, Social, Tecnológico, de Entorno, de Legislación) A partir de estos análisis, obtenemos no solo una lista de riesgos, sino una valoración de estos en cuanto a su impacto (severidad), a su probabilidad de ocurrencia o repetición (frecuencia), y a lo fácil o difícil que es detectarlos cuando ocurren (detectabilidad). Esto es necesario, pues debemos priorizar —es decir, decidir— cuál riesgo se ataca primero. Puedes usar brainstorming con el equipo de proyectos para poner en discusión todos los riesgos que el equipo ve en el proyecto contactless. Luego se los clasiﬁca y pondera para administrarlos. De esta manera, se ingresa en la etapa de respuesta al riesgo, que viene dada, consecuentemente, por las opciones que tenemos a la hora de enfrentarlo: La anulación del riesgo: eliminación total de la causa que provoca el riesgo. La mitigación del riesgo: reducción del impacto esperado o de la probabilidad de ocurrencia de la causa del riesgo. La aceptación del riesgo: aceptación de las consecuencias que pueden traer aparejadas las situaciones o las causas que lo provocan, y prever contramedidas en caso de que ocurra. La transferencia del riesgo: cambiar de lugar o de responsabilidad el efecto del riesgo. Por ejemplo, subcontratando proveedores o generando actividades de alto conocimiento especíﬁco. El manejo del riesgo puede llevar a la situación extrema de tener que cambiar el proyecto, en la medida en que la probabilidad de que ocurra sea verdaderamente alta y el equipo de trabajo no tenga una respuesta favorable para revertir tal situación. Esto es evitar el riesgo. Otras veces, las situaciones de riesgo, si bien no obligan a parar el proyecto, si obligan a redeﬁnir su alcance, los tiempos asociados y los costos de implementación. Figura 3: Impacto vs. probabilidad del riesgo Fuente: Abogacía española, s. f. content/uploads/2016/03/ABOGACIA-riesgos-ebook-ok.pdf https://www.abogacia.es/wp- La tercera dimensión que se agrega al gráﬁco de impacto vs. probabilidad de ocurrencia es el costo de la respuesta. Este concepto tiene una importancia muy grande, pues un excesivo costo de respuesta a una situación de riesgo puede hacer fracasar el proyecto por completo. Queda claro que a medida que la probabilidad de que ocurra un riesgo y su impacto sean altos, será proporcionalmente más alta la necesidad de respuesta, lo cual obligará a revisar el plan de acción propuesto para anular o mitigar el riesgo. Administración del costo Esta área o proceso es la responsable de estimar los costos de un proyecto, conocer las principales herramientas de estimación de estos, determinar el presupuesto y conocer la relación tiempo/gastos para estimar los cash ﬂows requeridos. Brevemente, cada responsabilidad se detalla como sigue: Planiﬁcar los costos – Es el proceso de establecer y documentar las políticas y procedimientos que se van a llevar a cabo para gestionar, ejecutar y controlar los costos a lo largo del proyecto. La salida de este proceso es el plan de gestión de costos. Estimación de costos – Este proceso es la estimación aproximada de los recursos monetarios necesarios para completar las actividades del proyecto, lo cual está muy relacionado con la estimación de los recursos de las actividades. El origen de los costos es variado: el personal, los materiales, el equipamiento, los servicios, las instalaciones, el factor de inﬂación, el costo ﬁnanciero, el costo de contingencia, etc. Determinar el presupuesto – Este proceso es el resultado de sumar los costos estimados de las actividades individuales o paquetes de trabajo del proyecto. El objetivo consiste en establecer la línea base de costos autorizada con la que monitorear y controlar el proyecto. Las salidas principales del proceso serán el presupuesto —que contiene los fondos autorizados para llevar a cabo el proyecto— y los requisitos de ﬁnanciación del proyecto. Conocer la relación tiempo/gastos (PERT/Cost) – Es una técnica para monitorizar los costos de ejecución de un proyecto, es una extensión del PERT (en español, Técnica de Revisión y Evaluación de Programas) de tiempos. Incorpora explícitamente la incertidumbre en cuanto a la duración de las actividades en el costo de un proyecto. ¿Puedes estimar el costo individual de una tarea? ¿Y de un recurso? Si no puedes, toma ejemplos de otros proyectos o subdivide las tareas en tareas más simples y prueba de nuevo. Para la construcción del presupuesto se utilizan técnicas incrementales o decrementales, en función de si se dispone de un ﬁnanciamiento de arranque o si se va a conseguir con base en los costos. El siguiente gráﬁco ilustra las componentes del presupuesto: Figura 4: Componentes del presupuesto Fuente: elaboración propia. Administración del tiempo Es más propiamente conocida como gestión del cronograma, ya que el tiempo transcurre y no se puede administrar, porque está fuera de nuestro control. Es la gestión destinada a administrar el tiempo asignado a cada actividad y a las actividades necesarias para la concreción de los objetivos. Sus características son: Entender la gestión del cronograma de actividades del proyecto. Deﬁnir y secuenciar las actividades de un proyecto. Estimar los recursos de las actividades. Desarrollar un cronograma mediante distintas técnicas: PERT, CPM, etc. Durante la etapa de planiﬁcación de gestión del cronograma, se establecen los procedimientos, normas y documentos necesarios para planiﬁcar, desarrollar, ejecutar y controlar el cronograma del proyecto. La salida de este proceso es el plan de gestión del cronograma, integrado al plan de dirección del proyecto. En el proyecto de implementación del contactless, ¿ya conoces el tiempo de entrega del hardware especíﬁco? Igual que en la administración del costo, subdivide si no puedes estimar la duración de una tarea individual. Una vez deﬁnidas las actividades, comienza el proceso que determina las dependencias, relaciones o secuencias requeridas entre las actividades identiﬁcadas del proyecto. Estas relaciones pueden ser: Tabla 1. Matriz de relaciones entre actividades Fuente: elaboración propia. Figura 5: Ejemplo de relaciones entre actividades Fuente: elaboración propia. Una vez deﬁnidas y secuenciadas las actividades, debemos estimar el recurso tiempo para cada una y para el cronograma total. Este proceso tiene como objetivo identiﬁcar la cantidad de períodos de trabajo necesarios para ﬁnalizar las actividades individuales con los recursos estimados. Para la estimación de los tiempos individuales por actividad, no tenemos muchas opciones y la herramienta más utilizada sigue siendo la opinión de expertos en el tema, quienes estiman, por analogía, la duración real de una actividad en función de datos históricos. C O NT I NU A R Lección 2 de 3 Referencias Abogacía española. (s. f.). Guías TIC: Gestión de riesgos. Recuperado de https://www.abogacia.es/wp-content/uploads/2016/03/ABOGACIA-riesgosebook-ok.pdf [Imagen sin título sobre grupos de procesos y areas de conocimiento]. (s. f.). Recuperado de https://wolfproject.es/curso/dinamica-procesos-pmbok-62017/ [Imagen sin título sobre interacciones de grupos de proceso a lo largo del trayecto]. (s. f.). Recuperado de https://wolfproject.es/curso/dinamicaprocesos-pmbok-6-2017/ Project Management Institute. (2017). A Guide to the Project Management Body of Knowledge. Londres, EN: Project Management Institute. Lección 3 de 3 Descarga en PDF Módulo 3 - Lectura 3.pdf 851.6 KB Factores críticos de éxito ¿Qué consecuencias produjo una actualización de U$D 400 millones a la cadena de suministro de Nike y los sistemas ERP (sistema de planiﬁcación de recursos empresariales)? Todo esto fue en el año 2000. Los horrendos resultados se debieron a un audaz proyecto que incluía un ERP —un software para cadena de suministro— y un CRM (Customer Relationship Manager) que tenía como objetivo actualizar los sistemas. «Pensé que no íbamos a hablar sobre i2», dice Roland Wolfram, vicepresidente de Operaciones Globales y Tecnología de Nike, con los ojos deslumbrados y con ira mal ocultada a su gerente de Relaciones Públicas. Wolfram llama al problema “i2”. Este consistió en un error de software que le costó a Nike más de U$D 100 millones en ventas perdidas; redujo el precio de sus acciones en un 20 %; desencadenó una serie de demandas colectivas; y provocó en su presidente y CEO, Phil Knight, un famoso lamento: «Esto es lo que obtienes por U$D 400 millones, ¿eh? Un golpe de velocidad». En el negocio del calzado deportivo, solo Nike —con una participación de mercado mundial del 32 % (casi el doble que Adidas, su rival más cercano) y una capitalización de mercado de U$D 20 mil millones— es más activo que el resto de fabricantes y minoristas de la industria. Esto enloquece a Wolfram, porque mientras el resto del mundo conoce a su compañía por su marketing y su asociación con los atletas más famosos del mundo, el mundo de TI piensa en Nike como la compañía que arruinó su cadena de suministro. Especíﬁcamente por la demanda de i2, un motor de planiﬁcación que, en el año 2000, creó pedidos de miles de zapatillas Air Garnett —más de las que el mercado tenía apetito — y pidió miles de Air Jordan menos de lo necesario. «Para las personas que siguen este tipo de cosas, nos convertimos en un póster de implementaciones fallidas», dijo Wolfram. Pero también hubo una lección para las personas que, de hecho, siguen “este tipo de cosas”, especíﬁcamente, los CIO (directores de comunicaciones). La lección que surgió de la falla de Nike y su posterior rebote radicó en el hecho de que la empresa tenía un plan de negocios ampliamente comprendido y aceptado en todos los niveles de la empresa. Teniendo en cuenta esto y la capacidad de recuperación que de la empresa, al ﬁnal la falla i2 resultó ser, de hecho, solo un «aumento de velocidad». (Evaluando ERP, s. f., https://www.evaluandoerp.com/softwareerp/implementar-erp/implementaciones-fallidas-erp/). Factores críticos de éxito Video conceptual Referencias Revisión del módulo Descarga en PDF Lección 1 de 5 Factores críticos de éxito Factores críticos de éxito PRE S E N TA C I Ó N D E L C A S O Continuando con el caso de la lectura 4 del módulo 1, eres analista sénior del área de TI de un gran hipermercado y por tus manos pasan diariamente miles de datos e información acerca de personas, productos, estados de cuenta, direcciones de correo, etc. También eres responsable del manejo de una parte de la infraestructura asociada con las ventas del hipermercado, especíﬁcamente todo lo asociado a medios de pago. En ese rol tienes que administrar las terminales POS (point of sale) y todas las capas de software asociadas a autorizaciones de pago e imputación a estados contables. Al analizar una posible reducción de costos de infraestructura de TI, estás viendo la opción de externalizar completamente el cómputo y el almacenamiento de los datos relativos a las operaciones electrónicas de pago, lo cual es una revolución total para la cultura de la organización. Y te preguntas: ¿Qué factores de éxito puedo presentar como posibles al top management para conseguir la aprobación del proyecto? ¿Por qué fracasan los proyectos de TI? Dijimos en lecturas anteriores que una característica de los sistemas de información mal organizados o mal administrados es no poder aportar a los usuarios información libre de errores y oportuna. Esto se cumple para muchas organizaciones que no hacen inversiones en los sistemas de información. Las organizaciones tradicionales tienden a crecer de manera independiente, sin un plan que sea abarcativo a todas las áreas de la compañía. Sin embargo, no es esta la única razón para el fracaso de los proyectos de TIC. Veamos algunas estadísticas. Figura 1: Encuesta Robbins Gioia e implementación de ERP Fuente: Intesys Consulting, s. f., www.intesysconsulting.com Externalizar la gestión y el almacenamiento de los datos no es solo un proyecto de TI, es un cambio de cultura de la organización. Prepárate para lidiar con cuestionamientos no técnicos. La consultora KPMG realizó un seguimiento en Canadá sobre la tasa de éxito de los proyectos relacionados a TI de sus clientes. Considerando que aproximadamente se invierten en proyectos de TI unos U$D 25 000 millones en Canadá anualmente, el estudio indicó que indudablemente el gasto en fracasos de proyectos de TI se puede cuantiﬁcar en miles de millones de dólares. A continuación, algunas de sus conclusiones. Figura 2. Encuesta KPMG Fuente: Intesys Consulting, s. f., www.intesysconsulting.com El estudio OASIG (1995) se llevó a cabo bajo los auspicios del grupo del mismo nombre, el cual tiene interés especial en el Reino Unido y se ocupa de los aspectos organizativos de la tecnología de la información. La información se recopiló en el Reino Unido a partir de una muestra de 45 expertos, empleados principalmente por universidades o consultorías. En promedio, cada uno tenía más de 20 años de experiencia personal, lo que representa una base de conocimientos acumulada de más de 900 años. El OASIG extrajo su opinión de una muestra de aproximadamente 14 000 organizaciones usuarias. De estos entrevistados, 31 (69%) incluyeron el trabajo de consultoría como un componente importante de su trabajo y 27 (60%) incluyeron la investigación; muchos hacían ambas cosas. Sus áreas profesionales de especialización cubrían los dominios de administración, negocios y ciencias sociales. Unos pocos entrevistados tenían experiencia en ingeniería. Los resultados fueron los siguientes: Figura 3: Encuesta OASIG Fuente: Intesys Consulting, s. f., www.intesysconsulting.com Lo interesante de esto es analizar la composición de las causas de las fallas de los proyectos. En la encuesta de la consultora Bull, también de Inglaterra, se obtuvieron los siguientes resultados: Figura 4. Encuesta de Bull Fuente: Intesys Consulting, s. f., www.intesysconsulting.com Fíjate los motivos de fallas en los proyectos de TI según la consultora Bull, ¿puedes decir cuál se debe a una deﬁciente administración del proyecto y cuál a factores tecnológicos? Ten en cuenta esto al contratar proveedores para data centers. Factores no técnicos a considerar Los factores que atentan contra los proyectos pueden ser muchos y muy variados, pero hay algo claro: la responsabilidad de que se concreten de manera exitosa o no será, en primer lugar, de los directores, por su rol de administradores del proyecto. Consecuentemente, quienes ocupen estos roles deben tener una actitud proactiva en forma permanente, a ﬁn de encontrar aquellos aspectos que diﬁculten que el proyecto llegue a ser exitoso. Los factores o conceptos no técnicos más importantes que pueden afectar de manera negativa a un determinado proyecto son los siguientes: El poder y la política – En general, la estructura que se le asigna a modo de soporte a un proyecto tiene una dependencia matricial con respecto al administrador. El proyecto en sí mismo se nutre, por un lado, de personas que conforman el equipo de trabajo especíﬁco y, por otro, de personas que pertenecen a otras áreas de la organización y que, por razones obvias, reportan formalmente a otros líderes. Un ejemplo de esto son las personas que contratan personal, las que realizan las compras, las que confeccionan los pagos a proveedores, etc. Es por lo expuesto que una de las realidades que al administrador de un proyecto le toca en suerte afrontar es la relación con las estructuras matriciales, con las que cuenta para encarar cada una de las actividades que surgen de la planiﬁcación. Esto es, poner a prueba su capacidad política, que debe entenderse como la posibilidad de hacer. Estrictamente hablando, el administrador del proyecto debe tener la capacidad y la habilidad política para relacionarse con quienes tienen el poder y la posibilidad de inﬂuir sobre aquellos que harán que las directivas del administrador sean respetadas por la estructura formal que no le reporta directamente. Identiﬁcación de las necesidades – Muchas veces los proyectos producen bienes o servicios que carecen de utilidad para los usuarios ﬁnales. Muchas veces estos proyectos, que fueron deﬁnidos por la organización como un ente abstracto, no tuvieron en cuenta las necesidades de quienes verdaderamente van a usar ese bien o servicio. Esto puede llevar a un fracaso, no porque no se haya cumplido en tiempo y forma con el desarrollo, sino porque no se consideraron las necesidades de las personas. Las causas de esto son muy variadas: no se hace un relevamiento correcto de las necesidades; no se consulta al usuario ﬁnal; no se da lugar a los mandos medios para que sean ellos quienes especiﬁquen el proyecto; etc. Conocer al detalle las necesidades de aquellos a quienes está dirigido el proyecto es fundamental, pues van a ser los que lo apoyarán de manera incondicional. Entender el juego de las variables – Quien administra debe comprender cuales son las variables relevantes para el proyecto y tenerlas bajo control. Existen distintos tipos de variables, entre ellas: las cuantitativas, como el tiempo, el dinero asignado; y otras que son cualitativas, como la calidad del producto ﬁnal, el ambiente de trabajo, la motivación del equipo de trabajo, la idoneidad de los recursos humanos. Estas últimas son difíciles de medir y la forma de hacerlo es a través de una medición indirecta sobre alguna variable cuantitativa. Por ejemplo, la motivación de la gente puede llegar a medirse por el tiempo que demanda la realización de una determinada tarea. La elección adecuada de las variables a considerar como métricas del proyecto es muy importante para poder gestionarlo. La importancia de entender qué variables medir y cuál es la relación entre ellas implica que el administrador pueda trabajar sobre cada una, a ﬁn de modiﬁcar o corregir alguna de las variables claves, como el tiempo. El equilibrio entre tiempo y resultado – Todo aquel que dirija un proyecto deberá buscar el justo equilibrio entre el tiempo y el resultado. La recomendación general es no considerar ninguna de las dos variables totalmente dependiente o totalmente independiente una de la otra. Hay reglas que intentan enmarcar esta relación a ﬁn de que el administrador las tenga muy en cuenta a la hora de llevar adelante un proyecto con éxito, a pesar de que pueda tener alguna demora en la ejecución de este. Estas reglas son: Fijado el tiempo máximo para entregar el proyecto, tratar de cumplirlo. Si por alguna causa no se pudiera cumplir con el tiempo, se deberá llegar a un acuerdo para acotar el resultado, con el objetivo de presentar algo concreto en la fecha establecida. Cumplido el punto anterior, consensuar la nueva fecha de entrega de los pendientes, sabiendo que no habrá más nuevas oportunidades. – Manejo adecuado de las reuniones Muchas organizaciones pasan gran parte de su tiempo en reuniones interminables y totalmente improductivas. Muchas veces el valor agregado que se saca de las reuniones a las que concurren los equipos de trabajo son escasas o nulas. Un factor clave de éxito es organizar todo lo relacionado a reuniones para que se transformen en cortas y productivas. – Entendiendo las comunicaciones La dinámica del trabajo en equipo —ﬁjada en una meta— es tratar de comunicarse con el objetivo de encaminar todos los esfuerzos hacia un mismo lado. Planteado así, el desafío más importante es en cuanto a la comunicación. El éxito de un proyecto pasa por comprender las conversaciones y entender los conceptos de “hablar”, “escuchar” y “entender el trasfondo”. De hecho, este tema ya tiene un proceso formal establecido en el PMBOK. C O NT I NU A R Lección 2 de 5 Video conceptual C O NT I NU A R Lección 3 de 5 Referencias Evaluando ERP. (s. f.). Implementaciones fallidas de ERP: 9 casos de fracasos y decepciones [Publicación en el blog de Evaluando ERP]. Recuperado de https://www.evaluandoerp.com/software-erp/implementarerp/implementaciones-fallidas-erp/ Intesys Consulting. (s. f.). La realidad de los proyectos de TI [Publicación en el blog de Intesys Consulting]. Recuperado de www.intesysconsulting.com C O NT I NU A R Lección 4 de 5 Revisión del módulo Hasta acá aprendimos La gestión de proyectos en las organizaciones y la documentación – Un proyecto es un esfuerzo temporal que se lleva a cabo para crear un producto, servicio o resultado único. Los proyectos se llevan a cabo para cumplir objetivos mediante la producción de entregables. Proyectos de tecnologías de la información (TI) – Un proyecto de tecnologías de la información intentará lograr los objetivos por medio de la implementación de las TI, las cuales no son un ﬁn en sí mismo, sino un medio para alcanzar otros objetivos preﬁjados por una organización. Administración del proyecto, el riesgo, el costo y el tiempo – Cada proyecto es único y por ende deberá llevarse a cabo teniendo cuenta sus particularidades, que dependerán, entre otros factores, del área involucrada, la infraestructura, el poder existente en la organización, la cultura organizacional, los tiempos asociados, el equipo de trabajo, la tecnología elegida, los estándares de calidad y las metodologías empleadas para llevar a cabo los planes de trabajo. Estos son algunos factores, pero no los únicos, que hacen que un proyecto se distinga de todos los demás. – Factores críticos de éxito Los factores que atentan contra los proyectos pueden ser muchos y muy variados, pero hay algo claro: la responsabilidad de que se concreten de manera exitosa o no será, en primer lugar, de los directores, en tanto son los administradores del proyecto. Consecuentemente, quienes ocupen estos roles deben tener una actitud proactiva en forma permanente, a ﬁn de encontrar aquellos aspectos que diﬁculten que el proyecto llegue a ser exitoso. C O NT I NU A R Lección 5 de 5 Descarga en PDF Módulo 3 - Lectura 4.pdf 616.9 KB

Gestión de Proyectos en Organizaciones y Documentación (Módulo 3)

Document Details

Tags

Related

Summary

Full Transcript

Upgrade to continue