31 mayo 2006

El Dr. House y los ámbitos de un proyecto

A muchos profesionales de los proyectos los temas tratados en este blog les pueden resultar muy alejados de lo que es su práctica diaria. Al ingeniero responsable de la construcción de una planta de regasificación debería importarle el diseño de los tanques de almacenamiento, las bombas de alta presión y los procesos de vaporización, entre otros detalles técnicos, mientras que a un ingeniero de software el entorno y las herramientas de desarrollo a utilizar, por citar un par de ejemplos. El resto son elementos colaterales que, aunque están ahí, se aperciben como aspectos que no hacen más que robar tiempo a lo que verdaderamente importa. La gestión es un mal menor. He de reconocer que hace tiempo mi visión no difería un ápice de la de los ejemplos anteriores, y la experiencia ha ido corroborando que esa visión estaba más o menos dentro de los cánones generalmente establecidos.

Sin embargo, aunque pueda ser a nuestro pesar, esta visión de las cosas no es muy afortunada. Puede que en una organización que ejecuta pocos proyectos simultáneamente, y todos ellos de poca entidad, esta perspectiva no llegue a causar estragos. Pero en todo aquello que exceda estos límites el panorama empieza a diferir bastante. Cuando el número de proyectos crece, así como el número de personas involucradas en cada uno de ellos o de proveedores, la complejidad creciente debida a la red de interrelaciones demanda más exigencia a la hora de organizarse y de cuidar el trato interpersonal. Mantener la perspectiva citada en estos casos sí causa verdaderos estragos. Otra cosa es que seamos realmente conscientes de ello –en mi opinión en muchos casos es más una cuestión de admitirlo que de ser consciente- debido a que el caos que nos envuelve diluye todos estos efectos negativos.

Decía que esta visión no es muy afortunada porque todo aquello relacionado con un proyecto se puede encajar dentro de tres ámbitos: el técnico, el gestor y el humano. El lector puede encontrar una descripción de estos ámbitos en este sitio. Obviamente, la estrecha visión con que hemos empezado este anuncio se reducía al ámbito técnico. Es curioso ver cómo esta visión sesgada está tan comúnmente arraigada en las organizaciones, quizás no tanto si caemos en la cuenta de que el conocimiento técnico es una condición estrictamente necesaria sin la que resultaría imposible ejecutar cualquier proyecto. Es una pena, sin embargo, que un mantenimiento extralimitado de esta actitud llegue a empañar el buen funcionamiento de los proyectos.

Un buen ejemplo lo encontramos en la popular teleserie House cuyo nombre lo recibe del protagonista de la misma, un médico que constituye todo un arquetipo de la elevación del ámbito técnico a su máxima expresión. El Dr. Gregory House es un profesional con grandes conocimientos médicos que lo han llevado a adquirir cierta reputación dentro de su disciplina. En el hospital en el que trabaja lidera un pequeño equipo de médicos que le ayudan en sus tratamientos. Huelga decir que su liderazgo está pura y únicamente basado en el manifiesto predominio de sus conocimientos médicos. Por el contrario, posee un carácter bastante peculiar y huraño, sólo tiene un amigo dentro del hospital y, al parecer, ninguno fuera de él ya que su vida social es un desastre. El trato emocional con los pacientes, a pesar de los indiscutibles resultados de sus tratamientos, deja bastante que desear, estando continuamente lidiando con demandas judiciales. Y su gestión es un puro desastre debido, entre otras cosas, a que ni tan siquiera forma parte de lo que considera que es su trabajo. Para House, el ámbito técnico es lo único que existe.

En una serie de capítulos de la segunda temporada asistimos a otro ejemplo grandioso de los comportamientos que a veces se pueden observar relacionados con la omnipotencia del ámbito técnico. Como consecuencia de la gestión deficiente de su equipo de colaboradores House es relevado temporalmente de su puesto de jefe de equipo, pasando a ser supervisado por uno de sus subordinados, el Dr. Foreman. Al cabo de unas semanas el fracaso de Foreman en sus nuevas responsabilidades se hace manifiesto y se vuelve al status quo original. La razón del fracaso de Foreman no se debe a su mala gestión –hacerlo peor que House constituiría una hazaña en sí misma, sino a que al pesar el ámbito técnico como una espada de Damocles, Foreman también ejerce su liderazgo basado en el conocimiento técnico y, dado que desde este punto de vista está por debajo de House, sus propios fantasmas le impiden tener la autoconfianza necesaria para desempeñar su cargo.

¿Nos resultan familiares este tipo de situaciones?

12 mayo 2006

Cómo gestionar la incertidumbre en los proyectos (3)

El método de la Cadena Crítica en una cáscara de nuez

Volvemos a la carga con la serie de anuncios dedicados a modos eficaces de dar cuenta de los efectos de la incertidumbre en la gestión de un proyecto. Damos continuación a los anuncios [1] y [2] de este blog. Concretamente, en este anuncio, nos ocupamos de un método basado en la aplicación de la Teoría de las Limitaciones de E. M. Goldratt, uno de cuyos ejes centrales ya fue abordado e ilustrado en una simulación en el anuncio dedicado a incertidumbre e interdependencia. Este método se conoce como Cadena Crítica y recibe el nombre de la generalización del concepto de camino crítico, ver este anuncio para más detalle, aunque no debe confundirse y/o limitarse a esa simple generalización ya que es muchísimo más que eso.

Aunque muchas de las ideas presentes en el Método de la Cadena Crítica ya estaban presentes en las mentes de muchos jefes de proyecto antes de su advenimiento, ver “A critical look at critical chain project management” de T. Raz, R. Barnes y D. Dvir en el nº 4 de diciembre de 2003 de la revista Project Management Journal para un análisis bastante crítico al respecto, no es hasta 1997 en que aparecen unificadas bajo un marco común, y de forma novelada, en el libro “Cadena Crítica” de Goldratt.

Para ver en qué consiste el método y cómo se aplica, consultar el siguiente tutorial.

03 mayo 2006

Series de datos y ley de Benford

El control de gestión de cualquier actividad empresarial, y el seguimiento de los proyectos en particular, es una actividad bastante ingrata en muchos casos y, por lo general, muy poco reconocida. No solamente debido a que, por mucho que se intente incidir en lo contrario, siempre es vista por todo aquél que tiene que aportar datos sobre ingresos, gastos, horas imputadas a proyecto, etc., como un acto de vigilancia policial, sino a que también es un acto muy humano hacer mañana lo que puede hacerse hoy -mañana era nunca y nunca llegaba pasado mañana, cantaba Joaquín Sabina. Y rellenar un parte de actividad, imputar costes y horas, no escapa a dicho toque de humanidad.

Pero este acto de procrastinación nunca es indefinido y se encuentra finalmente con un límite: el que marca el fatídico hito de control de gestión, por ejemplo. Concretamente el día antes de dicho evento es cuando el equipo de proyecto se dedica ha realizar el gran acto de memoria e intentar recordar cuántas horas dedicó a cada proyecto durante cada uno de los días del último mes, en el mejor de los casos; o cómo se distribuye el coste efectuado del mes en las diferentes partidas presupuestarias y/o tareas realizadas. Y cuando la memoria falla, otra característica bastante humana, vaya, es la de inventar.

Pongámonos en el lugar del atribulado controller. ¿Hay alguna forma de comprobar si los datos son reales o inventados? Los falsificadores de datos deberían ponerse a temblar, ya que parece ser que cuando la gente inventa números que parezcan verosímiles tiende a utilizar más el 5 y el 6 como cifras iniciales –entenderemos por cifra inicial la primera cifra del número, leyendo de izquierda a derecha, que es diferente de cero. ¿Algún problema con ello? Podría utilizarse algún mecanismo para que la cifra inicial de nuestros números inventados se distribuyera aleatoriamente de una forma más uniforme. No hay motivos para que el falsificador deje de temblar. Todo indica que las series de números de cualquier documento contable honesto siguen la ley de Benford, teniendo como cifra inicial el 1 la mayoría de las veces y disminuyendo su frecuencia a medida que la cifra inicial es mayor, siendo el 9 el que menos veces se repite. En concreto, el porcentaje de aparición se muestra en la tabla siguiente:

Cómo haría entonces nuestro atribulado controller para detectar una acción fraudulenta? Utilizando una herramienta del tipo que encontrará en este sitio, para comprobar si la serie de datos que le han proporcionado sigue o no la ley de Benford. Desafortunadamente no constituye una prueba definitiva ya que el avispado falsificador podría haber amañado los datos de forma que sigan la ley de Benford. En todo caso sería una forma de desenmascarar falsificadores ignorantes de la ley de Benford. El primero en sugerir el uso de la ley de Benford para detectar irregularidades en contabilidad fue el contable y matemático Mark J. Nigrini, en un artículo publicado en 1996 en el nº 18 del Journal of the American Taxation Association, titulado “A Taxpayer Compliance Application of Benford's Law” –ver en este sitio un artículo más accesible. Desde entonces los auditores están al tanto de este hecho. ¿Lo está el del lector? ¿Lo estaban los de la antigua Andersen cuando auditaban a Enron?...

Para finalizar, un gráfico comparativo que muestra cómo cantan los datos del falsificador a pecho descubierto o del que simula de forma aleatoria.