Enfoque de cartera de sistemas de información

A pesar de los más de 20 años de experiencia de las empresas con los sistemas de información (SI), los desastres en esa zona se siguen produciendo con una regularidad sorprendente. Según este autor, los directivos, tanto generales como de TI, pueden evitar muchos de estos fiascos evaluando los riesgos —por separado y como cartera— antes de la implementación. También señala que los proyectos difíciles requieren diferentes enfoques de gestión. Los principales determinantes del riesgo son el tamaño y la estructura del proyecto y la experiencia de la empresa con la tecnología implicada. Las empresas pueden utilizar una serie de preguntas para evaluar el riesgo y crear un perfil de riesgo que les ayude a elegir las mejores herramientas de gestión para proyectos de diferentes riesgos.

• Una importante empresa de productos industriales descubre un mes y medio antes de la fecha de instalación de un sistema informático que un$ 15 millones de esfuerzos para pasar de un fabricante a otro están en problemas y la instalación debe retrasarse un año. Dieciocho meses después, el cambio aún no se ha realizado.

• Los presupuestos de una gran empresa de productos de consumo$ 250 000 para que un nuevo sistema de información de personal basado en ordenador esté listo en nueve meses. Dos años después,$ Se han gastado 2,5 millones y se estima$ Se necesitan 3,6 millones más para completar el trabajo. La empresa tiene que detener el proyecto.

• Una institución financiera importante cae$ 1,5 millones por encima del presupuesto y 12 meses de retraso en el desarrollo de programas para un nuevo paquete de sistemas financieros, vital para el funcionamiento diario de uno de sus principales grupos operativos. Una vez que el sistema esté finalmente instalado, los tiempos medios de respuesta a las transacciones son mucho más largos de lo esperado.

¿Historias de los días de la primera y la segunda etapa de finales de la década de 1960 y principios de la de 1970?1 ¡No! Todos estos hechos tuvieron lugar en 1980 en Fortuna «500» empresas (podría haber seleccionado ejemplos igualmente dramáticos del extranjero). De una manera casi embarazosa de relatar, el día del gran desastre en un importante proyecto de sistemas de información (SI) no ha pasado. Dados los más de 20 años de experiencia de la empresa en el Estado Islámico, la pregunta es «¿Por qué?»

Mi análisis de estos casos y mi conocimiento de primera mano de varios proyectos de SI en los últimos diez años sugieren tres deficiencias graves en la práctica que afectan tanto a la dirección general como a la dirección del SI. Las dos primeras son no evaluar el riesgo de los proyectos individuales y no tener en cuenta el riesgo agregado de la cartera de proyectos. La tercera es la falta de reconocimiento de que los diferentes proyectos requieren diferentes enfoques de gestión. Este artículo se centra en estas deficiencias y sugiere formas de subsanarlas.

Elementos del riesgo del proyecto

El típico estudio de viabilidad de un proyecto cubre exhaustivamente temas como las ventajas financieras, las ventajas cualitativas, los costes de implementación, los objetivos y las fechas de finalización y los niveles de personal necesarios. En términos precisos y nítidos, los desarrolladores de estas estimaciones proporcionan una voluminosa documentación de respaldo. Sin embargo, solo en raras ocasiones abordan con franqueza el riesgo de retraso en el tiempo, sobrecostes, déficit técnico o fracaso absoluto. Más bien, niegan la existencia de esas posibilidades al ignorarlas. Asumen las habilidades humanas, los controles, etc. adecuados, que garantizarán el éxito.

Por riesgo Le sugiero exponerse a consecuencias como:

No haber obtenido todos, o incluso alguno, de los beneficios anticipados.

Costes de implementación que superan con creces los niveles planificados.

El tiempo de implementación es mucho mayor de lo esperado.

El rendimiento técnico de los sistemas resultantes resulta estar muy por debajo de la estimación.

Incompatibilidad del sistema con el hardware y el software seleccionados.

Este tipo de riesgos en situaciones prácticas, por supuesto, no son independientes entre sí; más bien, están estrechamente relacionados. Al hablar del riesgo, supongo que el director ha utilizado los métodos y enfoques adecuados para aplicar al proyecto (la mala gestión es obviamente otro elemento del riesgo). El riesgo, según mi definición, es lo que queda tras la aplicación de esas herramientas.

En mi discusión, tampoco estoy insinuando una correlación entre riesgo y malo . Estas palabras representan conceptos completamente diferentes, y la relación entre los dos normalmente es que los proyectos de mayor riesgo deben generar mayores beneficios para compensar el aumento de la exposición a la baja.

Al menos tres dimensiones importantes influyen en el riesgo inherente a un proyecto:

1. Tamaño del proyecto. Cuanto mayor sea en gastos en dólares, niveles de personal, tiempo transcurrido y número de departamentos afectados por el proyecto, mayor será el riesgo. Los proyectos multimillonarios obviamente conllevan más riesgos que$ 50 000 proyectos y, en general, afectan más a la empresa si el riesgo se hace realidad. Un problema relacionado es el tamaño del proyecto en relación con el tamaño normal de los proyectos de un grupo de desarrollo de sistemas. El riesgo implícito suele ser más bajo en un$ Proyecto de 1 millón de dólares de un departamento cuyo coste medio de empresa$2—$ 3 millones que en un$ 250 000 proyectos de un departamento que nunca se ha aventurado en un proyecto que cueste más de$50,000.

2. Experiencia con la tecnología. Debido a la mayor probabilidad de que se produzcan problemas técnicos inesperados, el riesgo del proyecto aumenta a medida que el equipo del proyecto y la organización de TI se familiarizan con el hardware, los sistemas operativos, el gestor de bases de datos y el lenguaje de aplicación del proyecto. Un proyecto que presenta un riesgo leve para un gran grupo de desarrollo de sistemas de vanguardia puede tener un riesgo muy alto para un grupo más pequeño y menos avanzado técnicamente. Sin embargo, este último grupo puede reducir el riesgo mediante la compra de habilidades externas para una empresa relacionada con tecnología de uso comercial general.

3. Estructura del proyecto. En algunos proyectos, la propia naturaleza de la tarea define por completo, desde el momento de la conceptualización, los resultados. Clasifico esos planes como altamente estructurados. Conllevan mucho menos riesgo que aquellos cuyos resultados están más sujetos al juicio del gerente y, por lo tanto, son vulnerables a los cambios. Los resultados de estos proyectos son fijos y no están sujetos a cambios durante la vigencia del proyecto.

Una compañía de seguros que automatiza la preparación de la cartera de tarifas de sus agentes es un ejemplo de un proyecto tan altamente estructurado. Al principio del proyecto, los planificadores llegaron a un acuerdo total en cuanto a las líneas de productos que se iban a incluir, el diseño de cada página y el proceso de generación de cada número. A lo largo del proyecto, no hubo necesidad de modificar estas decisiones; por lo tanto, el equipo se organizó para alcanzar un resultado estable y fijo, en lugar de hacer frente a un objetivo potencialmente móvil.

Todo lo contrario ocurrió en el proyecto de información sobre el personal que mencioné al principio, que era un proyecto de estructura baja. En esa situación, los usuarios no podían llegar a un consenso sobre cuáles deberían ser los resultados y estas decisiones cambiaban casi una vez por semana, lo que paralizaba el progreso.

Evaluación del riesgo

El gráfico I, al combinar las distintas dimensiones del riesgo, identifica ocho categorías de proyectos distintas, cada una de las cuales conlleva un grado de riesgo diferente. Incluso a este nivel tan intuitivo, esta clasificación es útil para separar los proyectos para tipos muy diferentes de revisión de la dirección. Las organizaciones del Estado Islámico lo han utilizado con éxito para distinguir el riesgo relativo para su propia comprensión y como base para comunicar estas nociones de riesgo a los usuarios y a los altos ejecutivos corporativos.

Anexo I Efecto del grado de estructura en el riesgo del proyecto

Una preocupación legítima es cómo garantizar que diferentes personas que vean el mismo proyecto lleguen a la misma evaluación aproximada de sus riesgos. Si bien aún no se sabe cuál es la mejor manera de evaluar esto, varias empresas han realizado avances significativos en la solución del problema.

El anexo II presenta, en parte, un método que una gran empresa desarrolló para medir el riesgo: una lista de 54 preguntas sobre un proyecto a las que el director del proyecto responde antes de que la alta dirección apruebe la propuesta y varias veces durante su implementación.

Ejemplo de cuestionario de evaluación de riesgos de un total de 54 preguntas Fuente: Este cuestionario es una adaptación del caso Dallas Tire, nº 9-180-006 (Boston, Massachusetts: HBS Case Services, 1980).

Esta empresa desarrolló las preguntas después de analizar detenidamente su experiencia con proyectos exitosos y fallidos. Incluyo algunos de ellos como ejemplo de cómo unir los conceptos y la práctica. Estas preguntas no se basan en ningún marco analítico y puede que no sean apropiadas para todas las empresas; sin embargo, representan un buen punto de partida y varias otras grandes empresas las han utilizado.

Tanto el líder del proyecto como el usuario clave responden a estas preguntas. A continuación, se concilian las diferencias en las respuestas. (Obviamente, el cuestionario proporciona datos que no son mejores que la calidad de pensamiento que se utiliza en las respuestas).

Estas preguntas no solo destacan los riesgos, sino que también sugieren formas alternativas de concebir y gestionar el proyecto. Si la puntuación de riesgo agregada inicial parece alta, el análisis de las respuestas puede sugerir formas de reducir el riesgo mediante la reducción del alcance, la tecnología de nivel inferior, varias fases, etc. Por lo tanto, los directores no deberían considerar el riesgo como un descriptor estático; más bien, su presencia debería fomentar mejores enfoques de la gestión de proyectos. Los números 5 y 6 de la sección de estructura son ejemplos particularmente buenos de preguntas que podrían provocar cambios.

Cuanto más alta sea la puntuación, mayor debe ser el nivel de aprobación. Solo el comité ejecutivo de esta empresa aprueba proyectos muy arriesgados. Este enfoque garantiza que los altos directivos sean conscientes de los peligros importantes y hagan las compensaciones adecuadas entre el riesgo, la estrategia y el beneficio. Los gerentes deberían hacer preguntas como las siguientes:

¿Las ventajas son lo suficientemente importantes como para compensar los riesgos?

¿Podrán sobrevivir las partes afectadas de la organización si el proyecto fracasa?

¿Los planificadores han considerado las alternativas adecuadas?

De forma periódica, se vuelve a responder a estas preguntas durante el compromiso para revelar cualquier cambio importante. Si todo va bien, el riesgo disminuye continuamente durante la implementación, a medida que el tamaño de la tarea restante disminuye y la familiaridad con la tecnología aumenta.

Las respuestas a las preguntas proporcionan una visión común entre los directores sénior, de TI y de usuarios en cuanto al riesgo relativo de un proyecto. A menudo, los fiascos se producen cuando los altos directivos creen que un proyecto tiene un riesgo bajo y los directores de TI saben que tiene un riesgo alto. En esos casos, es posible que los directores del Estado Islámico no admitan su evaluación porque temen que los altos ejecutivos no toleren este tipo de incertidumbre en el procesamiento de los datos y cancelen un proyecto que podría beneficiar a la organización.

Perfil de riesgo de cartera

Además de determinar el riesgo relativo de los proyectos individuales, la empresa debe desarrollar un perfil de riesgo agregado de la cartera de proyectos de sistemas y programación. Si bien no existe un perfil de riesgo correcto en abstracto, existen perfiles de riesgo adecuados para los diferentes tipos de empresas y estrategias. Por ejemplo, en un sector en el que el procesamiento de datos es intensivo o en el que los ordenadores son una parte importante de la estructura del producto (como la banca y los seguros), los directivos deberían preocuparse cuando no hay proyectos de alto riesgo. En ese caso, es posible que la empresa esté dejando un vacío en el producto o servicio para que lo llene la competencia. Por otro lado, una cartera repleta de proyectos de alto riesgo sugiere que la empresa podría ser vulnerable a las interrupciones operativas si los proyectos no se completan según lo previsto.

Por el contrario, en las empresas que dependen menos de la informática, el Estado Islámico desempeña una función rentable y útil, pero claramente de apoyo, y la dirección suele considerar que esta función es adecuada. En esos casos, las grandes inversiones en proyectos de alto riesgo, podrían ser más pequeñas que en el primer tipo de empresa.

Sin embargo, incluso en este caso, una empresa debería tener algunos proyectos tecnológicamente interesantes para garantizar el conocimiento de la tecnología de vanguardia y mantener la moral y el interés del personal. Por lo tanto, los perfiles de riesgo agregados de las carteras de dos empresas podrían diferir legítimamente. El gráfico III muestra con más detalle los problemas que influyen en el Estado Islámico para que se acerque o se aleja de las iniciativas de alto riesgo (el perfil de riesgo debe incluir los proyectos que vengan de empresas de software externas, así como los del grupo interno de desarrollo de sistemas).

Anexo III Factores que influyen en el perfil de riesgo de la cartera de proyectos

En resumen, es posible y útil hablar del riesgo del proyecto durante la fase del estudio de viabilidad. El análisis del riesgo puede resultar útil tanto para quienes trabajan en un proyecto individual como para el departamento en su conjunto. Este análisis sistemático no solo puede reducir el número de fracasos, sino que, lo que es igual de importante, su poder como enlace de comunicación ayuda a los directores y altos ejecutivos del Estado Islámico a llegar a un acuerdo sobre los riesgos que deben correr de acuerdo con los objetivos corporativos.

Enfoque de contingencia

Ahora la organización se enfrenta al difícil problema del funcionamiento del proyecto. Gran parte de la literatura y la sabiduría convencional sobre la gestión de proyectos sugieren que hay una forma única y correcta de hacerlo. Un tema similar sostiene que los directores deben aplicar de manera uniforme a todas esas empresas un conjunto adecuado de herramientas, métodos de gestión de proyectos y vínculos organizativos.

Si bien es posible que haya un conjunto de herramientas de uso general, la contribución que cada dispositivo puede hacer a la planificación y el control del proyecto varía considerablemente según las características del proyecto. Además, las formas de implicar al usuario (a través de los comités de dirección, la representación en el equipo o como líder (no profesional del DP ni del IS), también deberían variar según el tipo de proyecto. En resumen, no existe una forma universalmente correcta de ejecutar todos los proyectos. Los métodos generales de gestión de proyectos se dividen en cuatro tipos principales:

• Herramientas de integración externa incluir dispositivos organizativos y de otro tipo de comunicación que vinculen el trabajo del equipo de proyecto con los usuarios, tanto en el nivel directivo como en el inferior.

• Integración interna los dispositivos garantizan que el equipo funcione como una unidad integrada.

• Herramientas de planificación formal ayude a estructurar la secuencia de tareas con antelación y a estimar el tiempo, el dinero y los recursos técnicos que el equipo necesitará para ejecutarlas.

• Control formal los mecanismos ayudan a los directivos a evaluar el progreso y detectar posibles discrepancias para poder tomar medidas correctivas.

En el gráfico IV se muestran ejemplos de las herramientas de cada categoría que utilizan habitualmente las empresas. Los párrafos siguientes sugieren cómo el grado de estructura y la tecnología relativa a la empresa influyen en la selección de artículos de las cuatro categorías.

Anexo IV Herramientas de gestión de proyectos

Estructura alta, tecnología baja

Los proyectos muy estructurados y que presentan problemas técnicos conocidos no solo son los proyectos de menor riesgo, sino que también son los más fáciles de gestionar (consulte el gráfico I). También son los menos comunes. Estructura alta implica que los resultados están muy bien definidos según la naturaleza de la tarea, y la posibilidad de que los usuarios cambien de opinión en cuanto a cuáles deberían ser estos resultados es prácticamente inexistente. En consecuencia, los líderes no tienen que desarrollar procesos administrativos extensos para que un grupo diverso de usuarios acepte una estructura de diseño y la mantenga. Los dispositivos de integración externos, como la inclusión de analistas en los departamentos de usuarios, una fuerte representación de los usuarios en el equipo de diseño y la aprobación formal por parte de los usuarios de las especificaciones de diseño, son engorrosos e innecesarios para este tipo de empresa. Otros dispositivos de integración, como la formación de los usuarios sobre el funcionamiento del sistema, siguen siendo importantes.

Sin embargo, el concepto y el diseño del sistema son estables. Al mismo tiempo, dado que la empresa conoce la tecnología utilizada, el proyecto puede continuar con un alto porcentaje de personas que solo tengan una formación técnica y una experiencia media. El líder no necesita fuertes habilidades del Estado Islámico. Este tipo de proyecto brinda fácilmente la oportunidad a los directores subalternos del departamento, quienes pueden adquirir experiencia que podría llevar a tareas más ambiciosas en el futuro.

Los conceptos de planificación del ciclo de vida de los proyectos, que se centran en definir las tareas y presupuestar los recursos en función de ellas, obligan al equipo a desarrollar un plan exhaustivo y detallado (exponiendo las áreas de pensamiento blando del proceso). Es probable que estos proyectos cumplan con las fechas límite resultantes y se mantengan dentro del presupuesto objetivo. Además, las técnicas de control habituales para medir el progreso en función de las fechas y los presupuestos proporcionan datos muy fiables para detectar las discrepancias y generar una tensión deseable en el equipo de diseño para que se esfuerce más y evite retrasos.

Una cartera compuesta por 90% de este tipo de proyectos generarán poco entusiasmo entre los directores sénior y los usuarios. También requiere un conjunto de habilidades mucho más limitado para la organización de TI que el que podrían necesitar las empresas cuyas carteras tienen una mezcla de proyectos muy diferente. Un ejemplo de este tipo de proyectos es el proyecto de la libreta de tarifas de la agencia mencionado anteriormente.

Estructura alta: alta tecnología

Estos proyectos, mucho más complejos que los primeros, implican algunas modificaciones importantes con respecto a la práctica descrita en los manuales de gestión de proyectos. Un buen ejemplo de este tipo es la conversión de sistemas de un fabricante de ordenadores a otro sin mejoras (lo que, por supuesto, es más fácil decirlo que hacerlo). Otro ejemplo de este tipo de proyectos es la conversión de un conjunto de procedimientos manuales en un miniordenador con el único objetivo de realizar las mismas funciones con mayor rapidez.

Los mecanismos normales de enlace con los usuarios no son cruciales en este caso (aunque lo son en el siguiente tipo de proyecto), ya que los resultados están tan bien definidos por la naturaleza de la empresa que tanto el desarrollo de las especificaciones como la necesidad de hacer frente a los cambios en los sistemas por parte de los usuarios son considerablemente menores. Sin embargo, el enlace con los usuarios es importante por dos razones: (1) para garantizar la coordinación de cualquier cambio en la entrada/salida u otros cambios de procedimientos manuales necesarios para el éxito del proyecto y (2) para hacer frente a cualquier reestructuración de los sistemas que se deba a deficiencias en la tecnología del proyecto.

No es raro en este tipo de proyectos descubrir durante la implementación que la tecnología es inadecuada, lo que obliga a posponerlo durante mucho tiempo mientras se elige una nueva tecnología o se recortan funciones vitales para que la tarea se ajuste a la tecnología disponible. En una de esas situaciones, una importante empresa de productos industriales tuvo que convertir algunos procedimientos computarizados de entrada de pedidos en manuales para poder cambiar el resto de un sistema integrado de gestión de materiales a un hardware nuevo ya comprado.

Estas deficiencias tecnológicas también fueron la principal dificultad de la institución financiera que describí al principio de este artículo. En ese caso, en el que el rendimiento del sistema es mucho peor de lo esperado, la participación de los usuarios es importante tanto para evitar la desmoralización como para ayudar a implementar un enfoque alternativo (un diseño menos ambicioso) o un acuerdo mutuo para poner fin al proyecto.

Sin embargo, las habilidades que conducen al éxito en este tipo de proyectos son las mismas que para una administración eficaz que implique cualquier tipo de complejidad técnica. El líder necesita esta experiencia (preferiblemente, pero no necesariamente, en un entorno de TI) además de experiencia administrativa, a menos que el proyecto no sea muy grande. El líder también debe ser eficaz en la relación con los técnicos. Al hablar con el equipo de proyecto en varios momentos, el director ideal anticipará las dificultades antes de que los técnicos se den cuenta de que tienen un problema. Al abordar proyectos más grandes de esta categoría, la capacidad del director para establecer y mantener el trabajo en equipo a través de las reuniones, un registro de todas las decisiones clave de diseño y las conferencias sobre los subproyectos es vital.

Los métodos de planificación del ciclo de vida del proyecto, como la PERT (técnica de evaluación y revisión del programa) y la ruta crítica, identifican las tareas y las fechas de finalización adecuadas. Sin embargo, su valor predictivo es mucho más limitado en este caso que en la categoría anterior. El equipo no entenderá los elementos clave de la tecnología de antemano, y los errores aparentemente menores en estos proyectos tienen una curiosa forma de convertirse en una gran carga financiera.

En una empresa, aproximadamente una vez por hora, un sistema de banca en línea generaba basura en la pantalla del CRT. Mientras que con solo pulsar una tecla de lanzamiento se borraba esta pantalla de ceros y x, cuatro meses y más de$ Se destinaron 200 000 000 a eliminar la llamada pantalla fantasma. La solución consistía en descubrir una interacción compleja de las funciones del hardware, las funciones del sistema operativo y los patrones de tráfico de las aplicaciones. La corrección del problema finalmente requirió que el vendedor rediseñara varios chips. Y los mecanismos de control formales tienen límites a la hora de supervisar el progreso de estos proyectos.

En resumen, el liderazgo técnico y la integración interna son las claves de este tipo de proyectos, y la integración externa desempeña un papel claramente secundario. Las herramientas formales de planificación y control ofrecen proyecciones más subjetivas que concretas, y el gran peligro es que ni los directores del Estado Islámico ni los ejecutivos de alto nivel lo reconozcan. Puede que crean que tienen una planificación precisa y un control estrecho cuando, de hecho, no tienen ninguno de los dos.

Estructura baja, baja tecnología

Cuando estos proyectos se gestionan de forma inteligente, tienen poco riesgo. Sin embargo, estos proyectos fracasan una y otra vez por una dirección inadecuada. En este sentido, se diferencian del primer tipo de proyecto, en el que unas habilidades de gestión más comunes podrían garantizar el éxito. La clave para llevar a cabo este tipo de proyectos reside en hacer un esfuerzo eficaz para implicar a los usuarios.

Es fundamental desarrollar un soporte sustancial para los usuarios solo para una de las miles de opciones de diseño y mantener a los usuarios comprometidos con ese diseño. Los aspectos esenciales de este proceso incluyen los siguientes:

Un usuario como líder del proyecto o la segunda persona del equipo.

Un comité directivo de usuarios para evaluar el diseño.

Un esfuerzo por dividir el proyecto en una secuencia de subproyectos muy pequeños y discretos.

Revisión y aprobación formales por parte de los usuarios de todas las especificaciones clave del proyecto.

Distribución de las actas de todas las reuniones clave de diseño entre los usuarios.

Hacer grandes esfuerzos para mantener al menos los horarios de los subproyectos principales por debajo de los tiempos normales de rotación de la dirección y el personal en las áreas de usuarios (ya que un consenso sobre el enfoque con el predecesor de un administrador de usuarios tiene un valor dudoso).

La debacle de la información sobre el personal que mencioné al principio de este artículo es un ejemplo de lo que puede ocurrir cuando este proceso no se lleva a cabo. Poco después de empezar el trabajo, el director de recursos humanos decidió que la participación de sus altos directivos en el diseño era una pérdida de tiempo y se aseguró de que ninguno de ellos participaba.

En lugar de acabar con la empresa de inmediato, el director del SI intentó seguir trabajando bajo el liderazgo de uno de sus empleados con orientación técnica y que tenía poca experiencia en el departamento de recursos humanos. Bombardeado por las presiones del personal de recursos humanos que no entendía, el director del proyecto permitió que el diseño del sistema se ampliara para incluir cada vez más detalles de dudoso mérito hasta que el sistema se derrumbó. El cambio de diseño hizo que gran parte de la programación quedara obsoleta. Un liderazgo firme y pragmático de los usuarios en la fase de diseño habría marcado la diferencia en el resultado.

La importancia del liderazgo de los usuarios aumenta una vez que el diseño es definitivo. Casi inevitablemente, en ese momento los usuarios crearán alguna versión de «He estado pensando…». A menos que los cambios deseados tengan una importancia estratégica fundamental para el usuario (es mejor que lo juzgue un director de proyectos responsable y orientado al usuario), las solicitudes deben desviarse y posponerse hasta que puedan tenerse en cuenta en algún proceso formal de control de cambios.

A menos que el proceso se controle rigurosamente (un problema que se agrava por la casi imposibilidad de distinguir entre las economías de una alternativa propuesta y las implícitas en el diseño original), los usuarios realizarán cambios tras cambios y el proyecto evolucionará rápidamente hasta convertirse en un estado de aplazamiento permanente, y siempre se completará dentro de seis meses.

Si el proyecto está bien integrado con otros departamentos, las herramientas de planificación formal serán muy útiles para estructurar las tareas y ayudar a eliminar cualquier incertidumbre restante. Las fechas límite de finalización se mantendrán firmes mientras el objetivo del sistema se mantenga fijo. Del mismo modo, los dispositivos de control formales ofrecen una visión clara del progreso realizado hasta la fecha, lo que indica tanto los avances como los retrocesos. Si la integración con los departamentos externos es débil, el uso de estas herramientas generará una sensación de confianza totalmente injustificada.

Por definición, los problemas de la gestión de la tecnología suelen ser menos difíciles en este tipo de proyectos que en las empresas de alta tecnología, y un personal con una mezcla normal de conocimientos técnicos debería ser adecuado.

De hecho, en casi todos los aspectos, la gestión de este tipo de proyectos es diferente a la de los dos anteriores. La clave del éxito es una gestión estrecha y agresiva de la integración externa, complementada con herramientas formales de planificación y control. El liderazgo debe provenir del usuario y no del aspecto técnico.

Estructura baja: alta tecnología

Como estos proyectos son complejos y conllevan un alto riesgo, sus líderes necesitan experiencia técnica, conocimientos y capacidad de comunicarse con los usuarios. Aquí es necesario el mismo esfuerzo intensivo de integración externa descrito en la clase de proyectos anterior. Es fundamental que los usuarios se comprometan totalmente con un conjunto determinado de especificaciones de diseño y, una vez más, deben aceptar una de las miles de opciones.

Sin embargo, lamentablemente, una opción deseable desde la perspectiva del usuario puede resultar inviable en el sistema de hardware y software seleccionado. En los últimos años, estas situaciones se han producido, especialmente con los diseños de sistemas de miniordenadores independientes, y suelen llevar a una reestructuración significativa del proyecto o a su eliminación por completo. En consecuencia, los usuarios deben estar bien representados tanto a nivel de políticas como de operaciones.

Al mismo tiempo, las consideraciones técnicas hacen que un liderazgo técnico sólido y una integración interna del proyecto sean vitales. Este tipo de esfuerzo requiere los líderes de proyectos más experimentados y necesitarán el apoyo incondicional de los usuarios. Al aprobar un proyecto de este tipo, los directores deben enfrentarse a la pregunta de si pueden o deben dividirse en una serie de problemas mucho más pequeños o utilizar una tecnología menos innovadora.

Si bien las herramientas formales de planificación y control pueden resultar útiles en este caso, en las primeras etapas contribuyen poco a reducir la incertidumbre y a resaltar los problemas. Las herramientas de planificación permiten al director estructurar la secuencia de tareas. Lamentablemente, en este tipo de proyectos surgen nuevas tareas con una regularidad monótona y las tareas que parecen simples y pequeñas de repente se vuelven complejas y prolongadas. El tiempo, el coste y el rendimiento técnico resultante resultan casi imposibles de predecir simultáneamente. En el proyecto lunar del Apolo, por ejemplo, el logro del rendimiento técnico era clave, y el coste y el tiempo simplemente disminuyeron. En el sector privado, con demasiada frecuencia este es un resultado inaceptable.

Enfoque de contingencia

El gráfico V muestra la contribución relativa que cada uno de los cuatro grupos de herramientas de gestión de proyectos hace para garantizar el máximo control, dado el riesgo inherente al proyecto. Revela que los directores necesitan estilos y enfoques muy diferentes para gestionar los diferentes tipos de proyectos de forma eficaz. Aunque el marco podría hacerse más complejo incluyendo más dimensiones, eso no haría más que confirmar esta conclusión principal.

Prueba V Contribución relativa de las herramientas a garantizar el éxito del proyecto

El manual corporativo habitual sobre gestión de proyectos, con su enfoque unidimensional, no aborda la realidad de la tarea a la que se enfrentan los directores actuales, especialmente los que se ocupan de los servicios de información. El enfoque correcto se deriva del proyecto y no al revés.

La necesidad de abordar la cultura corporativa en la que operan tanto la TI como la gestión de proyectos complica aún más los problemas. El uso de herramientas formales de planificación y control de proyectos tiene muchas más probabilidades de producir resultados exitosos en un entorno altamente formal que en uno en el que la cultura predominante sea más personal e informal. Del mismo modo, la selección y el uso eficaz de los mecanismos de integración dependen en gran medida de la cultura corporativa.

Por lo tanto, el tipo de cultura empresarial complica aún más mis sugerencias sobre cómo se deben gestionar los diferentes tipos de proyectos. (¡Demasiados exdirectivos del Estado Islámico han hecho la fatal suposición de que estaban en una posición ideal para reformar la cultura corporativa desde su puesto!)

La última década ha supuesto nuevos desafíos para la gestión de proyectos de TI y la experiencia ha indicado mejores formas de pensar en el proceso de gestión. Mis conclusiones, entonces, son triples:

1. Seguiremos sufriendo grandes decepciones a medida que nos adentremos en nuevos campos. Sin embargo, hoy en día se pueden identificar las dimensiones del riesgo con antelación y se puede tomar la decisión de proceder o no. Si continuamos, a veces fallamos.

2. El trabajo del departamento de desarrollo de sistemas en conjunto puede considerarse una cartera. Otros autores han discutido cuáles deberían ser los componentes apropiados de esa cartera en un momento determinado. Sin embargo, el perfil de riesgo agregado de esa cartera es una decisión estratégica fundamental (aunque a menudo se pasa por alto).

3. La gestión de proyectos en el campo de la TI es compleja y multidimensional. Los diferentes tipos de proyectos requieren diferentes grupos de herramientas de gestión para tener éxito.

1. Richard L. Nolan y Cyrus F. Gibson, «Managing the Four Stages of EDP Growth», HBR, enero-febrero de 1974, pág. 76.