Proyectos: ¿Porque el índice de éxito es tan bajo?

44% de proyectos terminan siendo reorientados en tiempo, alcance y recursos

Por: Aarón Ballesteros Morales

Hace mas de 10 años que sigo leyendo afirmaciones contundentes como: “De acuerdo con un estudio de Standish Group, en el 2009 en Estados Unidos solo un 32% de los proyectos con alto contenido informático se pueden considerar exitosos, un 44% deberían ser reorientados en tiempo-alcance-recursos y un 24% fracasan. Además, se determinó que un 29,6% de los proyectos excederán las estimaciones iníciales de costos en más de un 50%”. Estando disponibles las buenas practicas del “Project Management Body Of Knowledge” (PMBOK) del “Project Management Institute” (PMI), entonces, surge la pregunta, ¿por qué?

Al realizar una encuesta casera a mis colaboradores y colegas sobre los conceptos de proyectos y operaciones, existe una confusión alarmante, por ejemplo, se confunde la operación por un tercero (“outsourcing”) de un Call Center, Mesa de Ayuda, Producción de Servicios TI específicos, la operación de un Centro de Datos, etc., como un proyecto y a cargo de un “Project Manager”, siendo esta de naturaleza continúa y no un esfuerzo temporal, con inicio y fin determinado para producir un producto, servicio o resultado único,  como es por definición un proyecto. A esto debemos añadir que la magnitud de los mismos, es pequeña y no pasa generalmente del millón de dólares, por lo tanto, lo mas probable es que la gestión del proyecto no este presupuestada.

Esta confusión, inicia la distorsión del manejo de un  “proyecto” porque evita que se utilicen los procesos de gestión de proyectos definidos por el  PMBOK y se pasa directamente a la fase de ejecución, dejando de lado las otras fases como inicio, planificación, monitoreo, control y cierre. Así por ejemplo, no se identifican a los “stakeholder”, menos se cuenta con un “project charter”, no se tiene un Plan de Gestión del Proyecto que incluya el alcance expresado como el desglose del trabajo a realizar, la lista de actividades, la estimación de recursos, el desarrollo de un presupuesto y cronograma, el establecimiento de roles y responsabilidades, la determinación de la calidad esperada y menos se tiene la aprobación formal del Plan.

Respecto al éxito (32%), reorientación (44%) y fracaso (24%) de los proyectos que cumplen con los requisitos del PMBOK para ser catalogados como tales, mi propia experiencia y los estándares que describen las buenas prácticas indican la ausencia de un “Sponsor” que como parte de su rol le corresponde aprobar  el Plan Final del Proyecto, brindar los recursos financieros, proteger al proyecto de la influencia externa y cambios, otorgar autoridad al “Project Manager” como responsable de la gestión del proyecto para lograr los objetivos del mismo, resolver los conflictos que se extienden mas allá del control del “Project Manager” y de ser el cliente, la aceptación formal de los entregables.

Project Manager

Lo expuesto también es válido para todo tipo de proyectos, sean estos de infraestructura, comunicaciones y hasta proyectos aeroespaciales que deben contar con un “Project Manager”. Lamentablemente y a veces por un tema de costos, se suele  seleccionar a un “Project Manager” con poco conocimiento y habilidad en la gestión de proyectos, y peor aún, no se le otorga suficiente autoridad, por lo tanto, se convierte en un Coordinador de Proyecto dirigido por un gerente funcional que es “propietario” de recursos en un determinado departamento.

A esto se suma la ausencia del uso efectivo de herramientas que permitan monitorear y controlar de manera integrada el alcance, tiempo, costo, calidad, talento humano, comunicaciones, riesgos, compras y administración de contratos, por consiguiente,  cualquier distorsión no se detecta a tiempo y no se toman las acciones correctivas del caso, impactando directamente en el alcance, tiempo, calidad y costos.

Lo descrito es un esbozo muy general de las probables causas del bajo éxito de los proyectos, es necesario realizar un análisis mucho mas acotado para un proyecto específico en “problemas” y que podría significar falta de experiencia en determinados tipos de proyectos y que conllevan a una inadecuada definición del alcance y estimación errónea de recursos, la empresa y su organización en relación a los proyectos, los intereses y conflictos existentes y la propia cultura empresarial.

Construcción de Software Orientado a los Servicios

Algunos siguen implantando ERP´s de los 90’s, mientras que muy pocos construyen sobre SOA

Escrito por: Aarón Ballesteros Morales

Una de las características comunes a la mayoría de empresas del sector comercial del siglo XX, ha sido carecer de una organización flexible para trabajar en mercados muy cambiantes, donde el  talento humano, procesos, tecnología y sistemas de información, actuando como un todo, no se desarrollaban lo suficiente y oportunamente para enfrentar el nuevo escenario, por lo tanto, anclaban a la organización evitando surcar espacios de nuevas oportunidades y colocándola permanentemente en situación vulnerable como consecuencia del ingreso de nuevos competidores, productos y servicios sustitutos y la mayor competitividad y flexibilidad de algunos actores intrépidos del mercado.

Al parecer, las prácticas empresariales todavía siguen siendo muy conservadoras, a tal punto que se concibe a una organización de adentro para afuera, es decir, se siguen centrando en la eficiencia operativa interna como medio de competitividad, por lo tanto, el mayor esfuerzo no es el planeamiento estratégico, sino el planeamiento y control de recursos a través del uso de  sistemas de información rígidos como los ERPs (“Enterprise Resource planning”), que cubren parcialmente  las funciones de una organización ya que requieren software complementario  y mucho trabajo manual adicional que involucra hojas de cálculo, dejando de lado el sueño de los años 90s, automatizar (antes decían mecanizar) todos los procesos empresariales.

Para hacer interesante el análisis planteo la siguiente pregunta: ¿un operador de telefonía o telecomunicaciones como Claro o Movistar deberían priorizar la automatización de sus procesos de soporte administrativo o fortalecer el marketing y las ventas con sistemas de soporte de negocios?. La realidad siempre nos ha mostrado que  los negocios empiezan fuera de la empresa, donde como producto de las estrategias de marketing y campañas de publicidad, se captan y retienen clientes cada vez mas, a través de medios virtuales y  Centros de Atención al Cliente, luego se procede a Proveer el Servicio de acuerdo a lo acordado y para ello la Gestión de la Provisión y Soporte Administrativo debe ser flexible y oportuno, donde el Aseguramiento de la entrega del Servicio con la Calidad ofrecida es vital, antes de proceder a la Facturación y al Cobro.

Lo expuesto muestra las actuales necesidades del mercado globalizado, que busca mayor flexibilidad en la producción y entrega de bienes y servicios que lamentablemente no se podrán  lograr oportunamente usando solamente los tradicionales ERPs y/o software complementario, ya que mayor competitividad requiere mayor flexibilidad. La empresa flexible se caracteriza porque esta capacitada para  satisfacer las demandas del mercado en periodos muy cortos; mantiene una adecuada relación con los clientes usando acuerdos de niveles de servicio; incorpora conceptos de gestión de procesos corporativos; gestiona proyectos basados en tiempo, calidad y costos; monitorea y controla resultados; así mismo, mide  el desempeño y la contribución individual y de equipo de los colaboradores, mediante indicadores.

En ambos casos, tanto para las empresas que tienen ERPs robustos y con años de funcionamiento y para las empresas que quieren empezar a utilizar uno, surge la misma pregunta: ¿El concepto de utilizar un ERP para hacer competitiva a la empresa sigue siendo vigente, rentable y efectiva  o existen alternativas mucho mas flexibles, escalables y de crecimiento a demanda ya sea por funcionalidad o presupuesto?. La respuesta como siempre es simple, existen otras alternativas y una de ellas es el  Software Orientado a los Servicios, a la que le he denominado SOS.

¿Qué es un SOS?. El SOS es un concepto  nuevo para construir software flexible utilizando todo el software desplegado que se utiliza para operar y gestionar el negocio, es decir, construir software utilizando componentes existentes y/o crear los adicionales que se necesiten. Con este enfoque moderno se podría  utilizar funciones de los actuales ERPs como servicios disponibles de propósito general, invocándolos cuando sea necesario como parte de nuestra plataforma y en caso de necesitar algún servicio adicional, este lo construimos bajo ciertos estándares para que nuestro SOS cubra los requisitos del negocio a demanda.

Para construir un SOS se debe contar previamente con un esquema global de una Arquitectura Orientada a los Servicios (SOA), que es una imagen completa que muestra los servicios del negocio (componentes de mayor tamaño -de grano grueso- que componen un software y estos se construyen a partir de otros servicios técnicos mas pequeños -de grano fino- que existen), la descripción de los servicios, métricas de rendimiento, estándares de interoperabilidad (como los sistemas hablan entre ellos),  esquema de datos, políticas y requisitos de clasificación y localización de datos.

¿Cómo se crean los componentes de software o servicios TI necesarios para el SOS?

A partir de docenas o cientos de aplicaciones y sistemas en plataformas heterogéneas que se utilizan en la operación cotidiana  y como silos de información que previamente se debe convertir a servicios TI. Para convertir y exponer estas aplicaciones rápidamente como servicios TI, existen herramientas como el ESB(“Enterprise Service Bus”) que brinda todas las instrumentos que necesita para crear servicios partiendo de la interfaz (XML, RMI, CORBA, COM, DCOM, RPC…,  API) es decir, la funcionalidad que un servicio proporciona y que es una actividad previa y diferente a la implementación, que determinará como se entrega esta funcionalidad.

¿Cómo evitamos el crecimiento descontrolado de las TI?

Lo propuesto requiere un  nuevo esquema global de la organización, es decir, una nueva organización para producir y entregar servicios TI en base a los requisitos del negocio y para ello se necesita una evaluación de competencias, delimitar responsabilidades entre proveedores y consumidores de servicios, establecer las políticas y los procesos implicados en la adopción de SOA, la declaración formal que oriente las decisiones y acciones futuras y sobre todo, el órgano de gobierno que las cree y aplique; estos evitarán la expansión descontrolada de los servicios de TI.

¿Como funciona un SOS?

Para crear un servicio el propietario del negocio brinda los requisitos para que se pueda implementar una funcionalidad, solución o proceso y también define requisitos no funcionales como la calidad del servicio, en base a estos requisitos el arquitecto diseña el servicio, los procesos e interfaces (funcionalidad) formalizando también los requisitos no funcionales como disponibilidad, seguridad y rendimiento. Por su parte, el desarrollador es el que implementa los componentes diseñados y crea los planes de pruebas.

Para asegurar la calidad, se utiliza la información del propietario,  arquitecto y desarrollador y en conjunto, se comprueba la prestación del servicio o proceso implementado, utilizando los planes de prueba validando las métricas de calidad, verificando los efectos no esperados y las características funcionales alcanzadas. Finalmente, el operador las despliega, poniendo en marcha la nueva solución virtualizada SOS.

Como producto de la construcción de un SOS, los procesos de negocios se construyen a demanda y sin restricciones técnicas que van mas allá de los sistemas ERP antiguos e inflexibles; la tecnología utilizada para construir software se mantiene actualizada y ya no dificulta la integración de antaño; los cambios en los proveedores  de software producto de adquisiciones o fusiones, no afectan directamente a las capacidades del software y su rumbo futuro;   los sistemas más antiguos a menudo llenos de información inaccesible para la creación de informes, estarán siempre disponibles; y lo mas interesante, se podrá comprar componentes de software o servicios a medida y disponibles cada vez mas y mas en un mercado SOA creciente.

PD. Según Forrester (www.forrester.com), el 71% afirmó que ya se encontraban usando SOA o que lo estarían haciendo para finales del 2011