El Negocio y los Proyectos TI

En una de mis entradas anteriores, Relaciones asimétricas, intentaba explicar un fenómeno que he visto en no pocas ocasiones y que, en mi opinión, resulta muy nocivo para cualquier Organización:

– La proliferación de soluciones TI críticas para el Negocio y que quedan fuera del control del Departamento de TI.

– La aparición de grupos de trabajo paralelos a TI que colaboran estrechamente con los usuarios para darles las soluciones que requieren.

Estas inquietudes han vuelto a mi mente al acabar de recibir una noticia que ahonda más aún en esta problemática. Os apunto la secuencia de hechos previos y la noticia:

  • En una organización (permitidme que no aporte más detalles), se arrancó un proyecto para la gestión electrónica de expedientes. Lo dirigía el Departamento de TI junto a una empresa externa.
  • A su vez, yo estaba gestionando otro proyecto para la misma organización. Mis usuarios e interesados lo eran también del proyecto mencionado.
  • Comencé por hablar con mis usuarios, para conocer su trabajo, sus necesidades, las de la organización y las expectativas de ambos.
  • Esto me llevó varias sesiones de charlas en que me iban contando cómo trabajaban, los problemas y dificultades que se encontraban y cómo las habían ido solucionando.
  • Uno de los usuarios clave para ambos proyectos, era una persona muy rigurosa, disciplinada y analítica. De los que da gusto que te den información porque te la dan documentada, con gráficos perfectos… Un lujo.
  • Esta persona me contó cómo para poder llevar un seguimiento de los expedientes que gestionaban en su área, desarrolló una aplicación en Access® que utilizaba todo el departamento.
  • También me contó el serio problema que tenían con el nuevo proyecto de gestión de expedientes. Llevaban muchos meses de retraso, él sólo tenía información “de pasillo” y nadie le había consultado ni preguntado. El Departamento de TI parecía saber cómo debían trabajar los usuarios y la herramienta que necesitaban.
  • Sólo en una reunión “pre-arranque” se le informó de lo que se había hecho. Él concluyó que no servía para las necesidades de su equipo y explicó por qué. Hubo que deshacer lo hecho y empezar prácticamente de nuevo; siguieron sin consultarle.
  • Casi tres años después de mi proyecto, mantenemos el contacto. En la última y reciente charla que hemos mantenido, me ha comentado que se ha desechado el proyecto de la gestión de expedientes y ya no está la empresa que lo llevaba.
  • Ahora va a ser el Departamento de TI el que va a desarrollar un nuevo proyecto, basado en la aplicación en Access® que mi interlocutor desarrolló hace años para su departamento.

Desgraciadamente situaciones como esta o similares no son inusuales y hacen mucho daño:

  • Las organizaciones arriesgan mucho dinero y trabajo en cada proyecto que acometen.
  • Se da por normal que muchos proyectos fallen, pero en algunos casos cuando se analizan las causas, sorprende que nadie lo anticipara.
  • Entre los directivos de las organizaciones aparece una gran inquietud ante todo aquello que tenga que ver con un Proyecto TI, porque no saben ni cuánto acabará costando, ni cuándo acabará ni cuánto va a “cabrear” a sus empleados.
  • Los buenos profesionales de la dirección de proyectos y sus equipos de trabajo, salen perdiendo. Cuando tienen que competir contra estos “Atilas” (por aquello de que no vuelve a crecer la hierba), estos últimos suelen ser más baratos, son muy “tecnólogos” y saben lo que hay que hacer y cómo antes de haber escuchado a nadie.

En mi opinión, casi tanta responsabilidad tienen estos profesionales “Atila” como quienes los contratan.

Según mi experiencia, cuando quien toma la decisión de a quién contratar es una persona del Negocio, que puede pertenecer al Departamento TI, las probabilidades de que se contrate a equipos que concluyan con éxito su trabajo es mucho mayor. En estos casos, el que toma la decisión se asegura de que entiende al proveedor (no habla “tecnológicamente”) y de que el proveedor va a entender lo que su organización necesita y va a trabajar para dárselo. Hablan en términos de Negocio. Adicionalmente hará que  otros miembros del Departamento de TI valoren aspectos técnicos.

Creo que nuestra profesión, la Gestión de Proyectos en general y la de Proyectos TI en concreto, necesita hacer una autocrítica, una revisión:

Son demasiados los proyectos que fracasan porque no se considera qué objetivos del Negocio se deben cubrir ni cuáles son las expectativas de los interesados.

Se focaliza en el cómo sin preocuparse apenas del para qué y para quién.

Salvo proyectos específicos, la tecnología es el medio, no el fin. He visto cómo se han subvencionado y otorgado proyectos cuya descripción se centraba en detalles técnicos  de la solución y apenas se mencionaba de forma muy genérica la necesidad o la funcionalidad para los interesados. Ninguno de estos proyectos que he seguido, está funcionando.

Para ampliar este argumento, os recomiendo la presentación de Steve Blais en el International Project Management Day 2012 de IIL, “Two for the Price of One”.

En todo proyecto, pero especialmente en los de cierta envergadura, debería haber:

  • Un Business Analyst, que conoce el Negocio, su problemática y propone la solución.
  • Un Project Manager, quien se responsabiliza de entregar la solución solicitada bajo el presupuesto, los plazos y los niveles de calidad acordados, con la satisfacción del cliente.
  • Un System Analyst (o Technical Leader), el responsable de hacer que el equipo técnico entregue la solución solicitada según las especificaciones indicadas.

Todos participan en aportar la solución al Negocio, pero como indica Steve Blais, la diferencia  está en dónde pone cada uno de ellos el foco.

  • El Business Analyst, está orientado al negocio/producto. Dirá qué se necesita y una vez entregada la solución, la validará y comprobará que efectivamente ha servido para lo que se solicitó.
  • El Project Manager, está orientado al proyecto. Se asegurará de entregar la solución solicitada en presupuesto, plazo y calidad, cubriendo las expectativas. Una vez hecho esto se dedicará a otro proyecto.
  • El System Analyst o Technical Leader, se focalizará en los aspectos técnicos. Se centrará en dar la mejor solución siguiendo las especificaciones planteadas. Una vez entregada la solución técnica, pasará a trabajar en otra solución.

Estas diferencias de visión, puestas a trabajar juntas, son las que hacen fuerte y exitosa a una organización. La clave está en la sinergia, en la participación y colaboración de todas sus partes como iguales. Es así como se discute, se confrontan diferentes puntos de vista y se llega a los mejores acuerdos:

Strength lies in differences, not in similarities.” – Stephen Covey.

¿Qué es lo que ocurre en muchas organizaciones como las del caso que ha dado entrada a este artículo?  Desde mi punto de vista se dan dos situaciones concurrentes:

  1. La organización hace que sólo exista un rol, el del System Analyst. Dado que la solución va a ser técnica, se deja todo el análisis de la necesidad y la gestión del proyecto en el técnico que la va a desarrollar y éste primará el aspecto técnico frente al de negocio y al proyecto.
  2. El Departamento de TI también ha puesto el foco únicamente en el desarrollo de la solución, no ha entrado a estudiar la necesidad de la organización, de sus usuarios y no ha gestionado un proyecto.

Por mi experiencia y como también señala Steve Blais, quizá en los proyectos de menor entidad estos roles puedan ser desempeñados por una persona (no es lo recomendable), pero debe asegurarse que los tres roles se cumplen aunque sea por la misma persona.

En los proyectos de cierta entidad, es indispensable que esos tres roles se desempeñen por distintos responsables y que trabajen juntos, sinérgicamente.

Mientras esto no se dé, seguiremos viendo proyectos fallidos, organizaciones castigadas y Departamentos de TI que no se integran en el Negocio.

Todas estas opiniones y reflexiones terminé de verlas respaldadas en otra presentación del mismo evento (International Project Management Day 2012 de IIL). Fue en la estupenda presentación de nuestra compatriota Isabel Ortiz, “Competencias clave del Director de Proyectos”.

En ella, Isabel Ortiz nos muestra el resultado de un estudio realizado por el Dr. Harold  Kerzner (“What Executives need to know about Project Management”. Harold Kerzner, PH.D. Frank P. Saladis, PMP). En una parte de dicho estudio se refleja cómo, a lo largo del tiempo, han ido cambiando los objetivos del proyecto y los resume en una tabla similar a esta:

OBJETIVOS   DEL PROYECTO

Tipos de Objetivos

Tradicional

(1960-1985)

Periodo de Renacimiento

(1986-1992)

Periodo Moderno

(1993-2009)

Técnicos

75%

50%

10%

Negocio

25%

50%

90%

Según mi experiencia, que he intentado compartir en este artículo, creo que en España, en muchos casos (afortunadamente no en todos), estamos en el primer periodo o Tradicional.

No hay más que echar un vistazo a las ofertas de empleo para Jefes de Proyecto, en cualquier portal de ofertas de empleo. Veréis cómo en un altísimo porcentaje (quizá más que 75% – 25%), se establecen como requisitos imprescindibles conocimientos técnicos muy especializados y concretos, dejando como deseados o sin demandar, otras competencias relacionadas con la gestión del proyecto. Se pone el foco en el aspecto técnico de la solución.

Creo que, como decía Abraham Maslow, “El que es hábil con el martillo tiende a pensar que todo es un clavo.”, y por esto, las organizaciones deben hacer trabajar juntas más habilidades, para ver más allá del clavo.

Considero que sería importante que fueran los mismos Departamentos de TI o técnicos en general, los que:

  • Exijan a la Organización que en los Proyectos de TI se consideren los tres roles mencionados y que, además,
  • sean proactivos en el esfuerzo de considerar, valorar y ponerse al servicio del Negocio y sus usuarios o interesados.

Estoy convencida de que el ratio de los proyectos con éxito aumentaría, trabajarían mejor y serían considerados una parte imprescindible y a tener en cuenta para la buena marcha del Negocio.

El Departamento de TI debe ser una parte vital de la anatomía del Negocio, no sólo una parte de la Organización.

Anuncios