Este artículo es un extracto de una tesis de maestría, realizada para obtener el tÍtulo de master en Gestión de Proyecto por la Universidad Pontificia de Salamanca.
Empecé dicha tesis motivada por los conceptos que rodean a los BPM y que cada vez toman más fuerza en el entorno; el ciclode vida de los procesos de negocio y el efecto del cambio en las organizaciones que deciden aplicar estos conceptos o cambiar su arquitectura por una orientada a procesos y/o servicios, es un largo proceso.
La inquietud era por qué no aplicar la guía del Project Management Body of Knowledge (PMBOK) para la gestión de un proyecto de estas características. Esta guía es un estándar en la gestión de proyectos desarrollado por el Project Management Institute (PMI), reconocido internacionalmente y que trabaja con el uso del conocimiento, de las habilidades, de las herramientas,y de las técnicas para resolver requisitos del proyecto. Esta guía define un ciclo vital del proyecto, 5 grupos de proceso y 9 áreas de conocimiento de la tarea de administración de proyectos.
Y esto me llevó a recorrer cientos de páginas web buscando algún rastro y/o antecedente al respecto; envié otros tantos correos a consultoras, pero nada encontré.
Al parecer nadie ha utilizado este estándar para proyectos BPM. Entonces decidí hablar de ello en mi tesis y ahora compartirlo con ustedes.
Unode los objetivos de dicho trabajo fue ‘Plantear el estándar PMBOK para la gestión de proyectos BPMS’. Como en cualquier otro tipo de proyecto, los proyectos para la implantación de sistemas de gestión de procesos de negocio, deben ser muy cuidadosos en su propia gestión.
La gestión de un proyecto BPM en general no sigue un estándar de gestión como podría ser ITIL o los fundamentos que reconoce el PMBOK (Project Management Body of Knowledge).
Para empezar, decidí identificar los beneficios de éste estándar, los factores que condicionan el éxito de un proyecto y cómo podría ayudar en los proyectos de implantación de sistemas de gestión de procesos de negocio.En la actualidad, la mayoría de los Modelos de Madurez en Gerencia de Proyectos tiene sus bases en éste estándar, por esta razón está recomendado como una herramienta que conlleva a la fácil implementación de CMMI (Capability Maturity Model Integration).
El ciclo de vida de desarrollo del BPM y el ciclo de vida de la gestión de proyecto de PMBOK, tienen cierta similitud en cuanto a que ambos trabajan con procesos.
Según PMBOK, un equipo de proyectos funciona en 9 áreas del conocimiento con un número de procesos básicos que se resume a continuación:
- Integración. Desarrolla la carta del proyecto, la declaración del alcance y el plan. Dirija, maneje, supervise y controle el proyecto de innovación.
- Alcance. Planeamiento, definición, creación, verificación y control de la estructura de división de responsabilidades del trabajo (WBS).
- Tiempo. Definición, estimación de recursos necesarios y duración; desarrollo y control del cronograma.
- Costo. Planeamiento de los recursos, costos estimados, presupuesto y control.
- Calidad. Planeamiento de la calidad, aseguramiento y control de la calidad.
- Recursos Humanos. Planeamiento, contratación, desarrollo y administración del recurso humano.
- Comunicaciones. Planificación, distribución de la información, difusión del desempeño; gestión de stakeholders.
- Riesgos. Planeamiento e identificación de riesgos. Análisis de riesgos (cualitativa y cuantitativa), planeamiento de la respuesta ante riesgos, supervisión y control.
- Aprovisionamiento. Plan de contrataciones y adquisiciones; administración y cierre de contratos.
Plantea que la dirección de proyectos es un esfuerzo integrador, es decir, los procesos y las áreas que la componen actúan como un sistema, donde las acciones o la falta de ellas en un área especifica repercuten en las demás.
Existen dos aspectos importantes relacionados con la dirección de proyectos:
- Las fases del proyecto y ciclo de vida del proyecto.
- Los interesados en el proyecto: director del proyecto, el cliente, el equipo que ejecuta el proyecto, los miembros del equipo de proyecto y el patrocinador. En términos de PMBOK, éstos se denominan Stakeholder.
Beneficios del PMBOK para los proyectos BPM
El nacimiento de proyectos que conllevan a un BPM, implica evolución, optimización e innovación en el negocio; objetivos por demás significativos para justificar una cuidadosa gestión del proyecto. En este sentido PMBOK ofrece beneficios tales como
- Ser un marco estándar de trabajo.
- Estar orientado a procesos.
- Indica el conocimiento necesario para manejar el ciclo vital de cualquier proyecto, programa y portfolio a través de sus procesos.
- Documentación de las lecciones aprendidas.
¿Por qué destacar las lecciones aprendidas?
Los registros históricos que podamos tener de la organización son muy útiles en el inicio de cada proyecto o en el inicio de cada fase y deben estar disponibles para todos los analistas y diseñadores. Y esto es independiente de la metodología que se aplique. Transmitir esas lecciones aprendidas sin duda reduciría el retrabajo de muchas tareas.
Pero esto requiere alimentar una cultura organizacional de aportación a la base de datos de conocimientos de la empresa, haciendo hincapié en los enormes beneficios que retornaran estas prácticas. Acometer cambios en la cultura organizacional no es tarea fácil, pero es necesario e importante para la vida de la empresa, conservar, almacenar, los conocimientos que se tienen de los procesos, ya sean de gestión o de trabajo.
Factores que condicionan el éxito de un proyecto
Al igual que en cualquier otro proyecto de implantación de una nueva tecnología, hay factores pueden contribuir o ser un obstáculo al éxito del proyecto. Pero más allá de lo evidente, el proyecto BPM tiene unas particularidades que condicionan unos factores de éxito y de riesgo muy específico.
Factores a considerar en fases tales como:
- El "punto cero":
- ¿Cuál es nuestro nivel de preparación para abordar el proyecto con éxito?
- El inicio:
- La presentación interna de la justificación de la inversión.
- La selección de la tecnología adecuada.
- Los procesos, Las personas.
- La organización.
- La construcción:
- La gestión del proyecto, Los usuarios.
- El ciclo de desarrollo.
- El "día después"
- El marketing del proyecto, La gestión de las expectativas.
- La continuación.
La consideración de estos factores a la hora de iniciar un proyecto de BPM, no es una receta. Sólo debe tomarse como una guía.
Otros estudios recopilados destacan los siguientes puntos clave que condicionan el éxito de un proyecto, sea o no BPM:
- La concurrencia del mercado.
- La mala definición del proyecto, las necesidades del cliente no fueron identificadas claramente.
- La mala formación del gestor de proyectos.
- ¿El desarrollo no ocurre según la previsión inicial?.
- ¿Hay muchos cambios de requisitos?.
- ¿Los recursos materiales y los trabajadores no son suficientes?.
- ¿Se suscitan luchas por prioridades entre proyectos?.
- ¿Mucho trabajo no cumple la calidad esperada y hay que volver a rehacer?.
- ¿El análisis no se hizo correctamente y aparecen temas imprevistos a mitad de camino?.
Son estas algunas de las preguntas que se me ocurre cuestionar a la hora de pensar por qué falla un proyecto. Sin embargo, podrían aparecen muchas más. Todo depende de la dimensión del proyecto y de las muchas variables que pueden influir.
Los proyectos de software son proyectos que tienen características muy particulares: sus entregables son digitales (programas, archivos fuente, diagramas, modelos, manuales, etc.), requieren mucha creatividad en la mayoría de sus fases, con tasas de fracaso de más del 70% (según el Standish Group).
Más cifras
- 75% de las empresas de software han sido calificadas como caóticas.
- El estrés causa el 40% de los errores en la creación o integración de aplicaciones.
- 84% de los proyectos de software fallan.
- 30% son cancelados.
- El resto sobrepasan el presupuesto.
Algunas de estas cifras motivaron a los equipos de desarrollo a cambiar las metodologías tradicionales y buscar alternativas a las sofisticadas herramientas CASE, como a la notación implícita en éstas.
Las ventajas del BPM están bien documentadas. Ya en 2004 un estudio de Gartner señalaba que el 78% de los proyectos BPM instalados con éxito daba un índice de retorno de inversión de más del 15%, y que algunos eran del 100% o incluso del 360%. El estudio también destacaba que más que en los esfuerzos de integración sistema a sistema propiamente dichos, BPM se centra principalmente en los procesos de negocio que requieren mucha intervención humana. Además de los retornos financieros, los usuarios citan constantemente como ventajas importantes la capacidad de BPM de reducir errores, mejorar los niveles de servicio e incrementar la visibilidad. Con esos resultados como referencia, Gartner pronostica que BPM continuará su ascenso como inversión prioritaria para las empresas que buscan mayores ventajas competitivas.
Los fracasos de proyectos existen en cualquier tipo de organización, da igual cual fuera su ámbito. Pero en Informática, cada año se cancelan miles de proyectos fallidos.
Existen "creencias"... causas ocultas del fracaso de proyectos que, supuestamente, están bien planeados y diseñados.
Muchos programadores creen que si se hacen buenas especificaciones, un buen diseño, una buena implementación y un buen control de calidad, entonces el proyecto funcionará. Personalmente, y coincidiendo con los textos consultados esto es falso. Esto es lo que se cree cuando el equipo no es un equipo, sino una serie de partes cumpliendo sus objetivos, de acuerdo a sus expectativas.
PMBOK como propuesta para la gestión de un proyecto
El gestor del proyecto debe ser el responsable de establecer el compromiso entre nivel de calidad – objetivos logrados, frente a tiempo – esfuerzo dedicados. A mayor tiempo y esfuerzo dedicados, mayor calidad y objetivos logrados, aunque también mayor coste.
En todo proyecto, es necesaria una persona encargada de velar por los intereses del cliente ante su empresa, y luchar por una correcta asignación de recursos y esfuerzos. Pero no sirve un gestor de proyecto incapaz de controlar la presión ejercida por el cliente y que solo se ocupa de traspasarla o multiplicarla hacia su equipo, una de las tareas más importantes será conseguir que el equipo pueda desarrollar su trabajo con normalidad.
En mi opinión, es fundamental disponer de una metodología adecuada, como así también una unidad de avance establecida. Y todo esto debe estar personalmente asumido y correctamente transmitido al resto del equipo.
Es un error definir una gestión del proyecto en base a la necesidad de información que la dirección de la empresa requiere de los proyectos, sin tener en cuenta sus características o las necesidades de los responsables, su finalidad es en primer lugar la de control, y después también la de comunicación. No tener esto claro, podría predestinar el proyecto a un fracaso escrito.
El proyecto no debe comenzar hasta que su alcance este revisado y se haya plasmado en una planificación. Y para ello PMBOK ofrece la Gestión de Alcances.
Potenciar la gestión frente a la calidad del trabajo
La calidad de un producto depende directamente de los procesos, materiales y técnicas usadas, por consiguiente, es importante que las compañías desarrolladoras de Software tengan en enfoque que la definición de un proceso de desarrollo y el uso de herramientas y técnicas apropiadas que garantizan un mejor funcionamiento y calidad del producto final y, por consiguiente, la mayor satisfaccióndel cliente.
Una parte crítica de la administración de proyectos de Software en general, y esto también afecta a los proyectos BPM, son los cambios y su evaluación de impacto durante el ciclo de vida aplicado. Cuando la alteración se propone mientras los requisitos están siendo reunidos, debe identificarse cómo la alteración afecta a otros requisitos. Si la alteración se propone mientras el sistema está en el desarrollo, o mientras los procesos se están ejecutando (en el caso de los proyectos BPM), el impacto de la alteración implica verificar cómo la alteración afecta los requisitos, el proyecto del sistema y su implementación. Si la alteración se propone después de que el sistema se puso en producción, también debe haber una comprobación adicional para identificar como todos los stakeholders del sistema pueden ser afectados por la alteración. En los BPM esto se hace en la fase de control o monitorización, según el ciclo de vida que se esté aplicando.
La gestión del riesgo
Dada la complejidad de los proyectos BPM desde el punto de vista de PMBOK, se propone una Gerencia de Riesgos que pretende identificar los factores que impacten a favor o en contra, los objetivos del proyecto, los tiempos y costos del mismo y los entregables del correspondiente proyecto. También permitirá cuantificar el impacto y la probabilidad de cada uno de ellos, generando una línea base que permitirá crear un plan de acción para responder a esos riesgos cuando se presenten y controlar esa respuesta.
PMBOK indica que la "Gerencia de Riesgos del proyecto" incluye los procesos relacionados con
- la planificación de la gestión de riesgos,
- la identificación y el análisis de los riesgos,
- las respuestas a los riesgos, y
- el seguimiento y control de los riesgos de un proyecto.
Es un proceso crítico, considerando que un riesgo puede representar una amenaza o una oportunidad para con los objetivos del proyecto.
Se sabe que a mayor oportunidad, mayor el grado de incertidumbre y por tanto, mayor el riesgo que se puede tomar y mayores las amenazas que se podrán presentar; esto sería un aliciente para justificar un modelo apropiado de la gestión de proyectos que me permita gerenciar los riesgos del mismo.
La gerencia de riesgos es muy diferente a la gestión de proyectos que conoce de procesos, resultados y una retroalimentación; pero los riesgos tienen que ver con impacto, probabilidad, incertidumbre y un plan de contingencia. Los resultados de esta gerencia de riesgos se traducen en términos de costos que afectarán al costo final del proyecto. Pero la valoración de esos riesgos no es fácil.
Los proyectos que se desarrollan con un ciclo de vida muy dinámico como son los BPM, requieren tener una buena identificación de riesgos, como así también una valoración o repuesta.
En cualquier proyecto que no sea BPM el proceso de identificación que debe comenzar desde que se inicia el ciclo de vida del proyecto, debe durar como mínimo hasta que comience la ejecución del proyecto. Pero en un proyecto BPM la identificación del riesgo debe mantenerse en todas las fases.
Conclusión
En este primer artículo he intentado transmitir la importancia de una buena gestión de proyectos y las ventajas que podría ofrecer el estándar PMBOK, destacando en particular la Gestión de Alcances y la Gestión de Riesgos. Pero no son las únicas importantes, como mencioné al principio son nueve áreas de conocimientos y que deberían trabajar en equilibrio.
Este estándar es sólo una guía Buenas Practicas qué, como dice uno de sus párrafos “Buenas prácticas” no quiere decir que los conocimientos descritos deban aplicarse siempre de manera uniforme en todos los proyectos: el equipo de dirección del proyecto es el responsable de determinar lo que es apropiado para cada proyecto determinado.
|
