Liderar un proyecto de TI y salir airoso
Cursillo acelerado para emprendedores
Los ejecutivos que acometen proyectos de desarrollo de sistemas necesitan maneras de evaluarlos en su proceso de definición, diseño y construcción. Hemos elaborado una especie de cuestionario para evaluar cualquier proyecto de desarrollo de TI, que revelará de manera bastante clara si se están haciendo las cosas bien, y servirá de cursillo acelerado al líder de un proyecto de TI.
En las primeras dos a seis semanas del proyecto -fase de definición- pregúntese y pregúntele al responsable a cargo del proyecto las siguientes cuestiones:
¿Cuál es la meta del proyecto?
En dos palabras o menos, constate los pasos que la empresa va a tomar y los resultados que se esperan derivar de dichas acciones. Esa es la meta. Tenga claro cuál es o abandone el proyecto.
¿Qué criterios de rendimiento son los aceptables para su sistema?
Constate los requisitos del sistema en estas cuatro áreas:
1- Operaciones de negocio
2- Expectativas del consumidor
3- Ejecución financiera
4- Aprendizaje y mejora para la compañía
Estas son las medidas específicas que determinarán si el sistema será un éxito. Asegúrese de que las conoce tanto usted como el equipo que lo diseña y construye.
¿Cree que un sistema que cumpla los requisitos de rendimiento mencionados servirá para conseguir la meta que busca?
Si tiene la sensación de que hay requisitos de rendimiento que no están en la lista y deberían, añádalos antes de que el proyecto siga avanzando, pero asegúrese de que se añaden requisitos que son estrictamente necesarios para llegar a los objetivos. Los requisitos que sean demasiado amplios derivarán en mayor complejidad y menos probabilidades de que el sistema se pueda construir satisfactoriamente.
¿Qué sistemas informáticos vigentes en su compañía quedarían detrás de su nuevo diseño?
El nuevo sistema debería al menos igualar los puntos fuertes de los sistemas y procesos ya existentes. De esa manera, podrá centrarse en ofrecer nuevas opciones en vez de tan sólo remplazar algunas de las que ya están en vigor. Si se decide remplazar todo y empezar desde cero, debe estar preparado para los gastos y el tiempo extra que esa decisión acarreará y asegurarse primero de que merecerá la pena.
¿El diseño general del nuevo sistema se puede dividir en un conjunto de subsistemas independientes que puedan operar cada uno por su cuenta y ser igualmente valiosos?
Los sistemas informáticos muy amplios están formados en realidad por un montón de subsistemas más pequeños. Su compañía debería ser capaz de construir cada subsistema independientemente de los demás. De esa manera, si uno de ellos tiene problemas, aún será posible funcionar con los otros. Conforme se vayan completando los subsistemas, deberían ponerse a trabajar lo antes posible para compensar el dinero que se ha invertido en ellos. Si todos ellos deben terminarse por completo antes de que se pueda utilizar cualquiera de ellos, estamos ante un diseño demasiado arriesgado: de todo o nada. Mejor cambiarlo.
¿Es correcto el análisis coste-beneficio del nuevo sistema?
Los cálculos coste-beneficio suelen disimular los gastos y exagerar los beneficios. Nadie mejor que usted podrá determinar la validez de los cálculos. ¿Cree que son correctos?
Cuanto más grande y arriesgado sea el proyecto, mayores tendrán que ser los beneficios
para justificar el riesgo y los gastos. No conviene gastar en un proyecto más de lo que realmente vale.
¿Cómo ha demostrado el encargado del sistema que su diseño y su capacidad de liderazgo son apropiadas para este tipo de proyecto?
Si el encargado de llevar a cabo el sistema no está cualificado, el proyecto fracasará por falta de dirección. La dirección en comité no funciona. Si esta persona no tiene las habilidades necesarias para diseñar y liderar, debe ser remplazado sin que importe las otras habilidades que pueda demostrar.
¿Cuáles de las líneas estratégicas se han seguido y cuáles no?
Si se siguen las siete líneas estratégicas (ver recuadro inferior) el diseño del sistema se puede considerar muy bueno. Si no se sigue una de ellas podemos considerarlo como aceptable, salvo que se trate del primer punto.
Si no se siguen dos, más vale que sea por razones muy poderosas. En ese caso, habrá que determinar qué precauciones extra habrá que tomar para compensar los posibles riesgos. Si no se siguen más de dos de las líneas estratégicas, el diseño no tiene arreglo. El sistema no podrá construirse ni en tiempo, ni acorde al presupuesto. Eso si se puede llegar a construir de alguna manera.
Progresos durante el desarrollo del sistema
Conforme el proyecto va avanzando por las fases de diseño y construcción, es necesario preguntarse, preguntar al encargado del sistema y a los equipos de proyecto las siguientes cuestiones:
¿Están en orden la planificación del proyecto y su presupuesto? ¿Se está siguiendo el plan con atención? ¿Hay un grupo dedicado que informe regularmente sobre el desarrollo del plan y el presupuesto?
Los proyectos de desarrollo de sistemas de varios millones de euros requieren de todo un equipo humano y consumen una considerable cantidad de tiempo. El plan del proyecto es el instrumento central de coordinación que informa exactamente a cada persona de lo que tiene que estar haciendo en cada momento. Si el plan no se actualiza, los involucrados en el proyecto no tendrán posibilidad de coordinar con eficacia su trabajo. El encargado perderá la pista de muchos detalles. Retrasos, excesos de gasto y confusión serán las consecuencias de este error. Nadie sabrá cuánto se ha gastado o cuánto hace falta todavía para terminar. Cuando esto suceda, el proyecto habrá entrado en una espiral mortal.
¿Están los equipos de los subsistemas organizando su trabajo en dos fases claramente distinguibles de diseño y construcción? ¿Se están llevando a cabo esas fases según el tiempo y el presupuesto planeados?
El equipo encargado de cada subsistema debería tomarse entre uno y tres meses para crear un diseño detallado y un prototipo del sistema (fase de diseño). El diseño detallado debería entonces convertirse en un sistema de trabajo en un plazo de dos a seis meses (fase de construcción). Si estas tareas llevan más tiempo del previsto, el proyecto se estará desarrollando demasiado despacio, perderá su energía y acabará zozobrando. Es responsabilidad del encargado del sistema mantener todo organizado y en movimiento. Asegúrese de que es una persona capaz.
¿Cómo se están aplicando los seis principios tácticos para desarrollar el proyecto (ver recuadro a la izquierda)? Puede el encargado explicarlo claramente, utilizando un lenguaje normal o se escuda en el uso continuo de jerga?
Alguien cualificado debe poder dar respuestas directas y claras. El encargado de la construcción del sistema es, en realidad, el principal responsable de la ejecución del trabajo.
De él depende que el proyecto sea un éxito o un fracaso. Si es preciso, mejor conseguir otro.
¿Cuál es la situación esta semana?
Compruebe en directo el plan y el presupuesto del proyecto cada cierto tiempo. Obligue al encargado del proyecto a revisar el plan en vigor conjuntamente, que le explique cuánto dinero se ha gastado hasta la fecha e
En las primeras dos a seis semanas del proyecto -fase de definición- pregúntese y pregúntele al responsable a cargo del proyecto las siguientes cuestiones:
¿Cuál es la meta del proyecto?
En dos palabras o menos, constate los pasos que la empresa va a tomar y los resultados que se esperan derivar de dichas acciones. Esa es la meta. Tenga claro cuál es o abandone el proyecto.
¿Qué criterios de rendimiento son los aceptables para su sistema?
Constate los requisitos del sistema en estas cuatro áreas:
1- Operaciones de negocio
2- Expectativas del consumidor
3- Ejecución financiera
4- Aprendizaje y mejora para la compañía
Estas son las medidas específicas que determinarán si el sistema será un éxito. Asegúrese de que las conoce tanto usted como el equipo que lo diseña y construye.
¿Cree que un sistema que cumpla los requisitos de rendimiento mencionados servirá para conseguir la meta que busca?
Si tiene la sensación de que hay requisitos de rendimiento que no están en la lista y deberían, añádalos antes de que el proyecto siga avanzando, pero asegúrese de que se añaden requisitos que son estrictamente necesarios para llegar a los objetivos. Los requisitos que sean demasiado amplios derivarán en mayor complejidad y menos probabilidades de que el sistema se pueda construir satisfactoriamente.
¿Qué sistemas informáticos vigentes en su compañía quedarían detrás de su nuevo diseño?
El nuevo sistema debería al menos igualar los puntos fuertes de los sistemas y procesos ya existentes. De esa manera, podrá centrarse en ofrecer nuevas opciones en vez de tan sólo remplazar algunas de las que ya están en vigor. Si se decide remplazar todo y empezar desde cero, debe estar preparado para los gastos y el tiempo extra que esa decisión acarreará y asegurarse primero de que merecerá la pena.
¿El diseño general del nuevo sistema se puede dividir en un conjunto de subsistemas independientes que puedan operar cada uno por su cuenta y ser igualmente valiosos?
Los sistemas informáticos muy amplios están formados en realidad por un montón de subsistemas más pequeños. Su compañía debería ser capaz de construir cada subsistema independientemente de los demás. De esa manera, si uno de ellos tiene problemas, aún será posible funcionar con los otros. Conforme se vayan completando los subsistemas, deberían ponerse a trabajar lo antes posible para compensar el dinero que se ha invertido en ellos. Si todos ellos deben terminarse por completo antes de que se pueda utilizar cualquiera de ellos, estamos ante un diseño demasiado arriesgado: de todo o nada. Mejor cambiarlo.
¿Es correcto el análisis coste-beneficio del nuevo sistema?
Los cálculos coste-beneficio suelen disimular los gastos y exagerar los beneficios. Nadie mejor que usted podrá determinar la validez de los cálculos. ¿Cree que son correctos?
Cuanto más grande y arriesgado sea el proyecto, mayores tendrán que ser los beneficios
para justificar el riesgo y los gastos. No conviene gastar en un proyecto más de lo que realmente vale.
¿Cómo ha demostrado el encargado del sistema que su diseño y su capacidad de liderazgo son apropiadas para este tipo de proyecto?
Si el encargado de llevar a cabo el sistema no está cualificado, el proyecto fracasará por falta de dirección. La dirección en comité no funciona. Si esta persona no tiene las habilidades necesarias para diseñar y liderar, debe ser remplazado sin que importe las otras habilidades que pueda demostrar.
¿Cuáles de las líneas estratégicas se han seguido y cuáles no?
Si se siguen las siete líneas estratégicas (ver recuadro inferior) el diseño del sistema se puede considerar muy bueno. Si no se sigue una de ellas podemos considerarlo como aceptable, salvo que se trate del primer punto.
Si no se siguen dos, más vale que sea por razones muy poderosas. En ese caso, habrá que determinar qué precauciones extra habrá que tomar para compensar los posibles riesgos. Si no se siguen más de dos de las líneas estratégicas, el diseño no tiene arreglo. El sistema no podrá construirse ni en tiempo, ni acorde al presupuesto. Eso si se puede llegar a construir de alguna manera.
Progresos durante el desarrollo del sistema
Conforme el proyecto va avanzando por las fases de diseño y construcción, es necesario preguntarse, preguntar al encargado del sistema y a los equipos de proyecto las siguientes cuestiones:
¿Están en orden la planificación del proyecto y su presupuesto? ¿Se está siguiendo el plan con atención? ¿Hay un grupo dedicado que informe regularmente sobre el desarrollo del plan y el presupuesto?
Los proyectos de desarrollo de sistemas de varios millones de euros requieren de todo un equipo humano y consumen una considerable cantidad de tiempo. El plan del proyecto es el instrumento central de coordinación que informa exactamente a cada persona de lo que tiene que estar haciendo en cada momento. Si el plan no se actualiza, los involucrados en el proyecto no tendrán posibilidad de coordinar con eficacia su trabajo. El encargado perderá la pista de muchos detalles. Retrasos, excesos de gasto y confusión serán las consecuencias de este error. Nadie sabrá cuánto se ha gastado o cuánto hace falta todavía para terminar. Cuando esto suceda, el proyecto habrá entrado en una espiral mortal.
¿Están los equipos de los subsistemas organizando su trabajo en dos fases claramente distinguibles de diseño y construcción? ¿Se están llevando a cabo esas fases según el tiempo y el presupuesto planeados?
El equipo encargado de cada subsistema debería tomarse entre uno y tres meses para crear un diseño detallado y un prototipo del sistema (fase de diseño). El diseño detallado debería entonces convertirse en un sistema de trabajo en un plazo de dos a seis meses (fase de construcción). Si estas tareas llevan más tiempo del previsto, el proyecto se estará desarrollando demasiado despacio, perderá su energía y acabará zozobrando. Es responsabilidad del encargado del sistema mantener todo organizado y en movimiento. Asegúrese de que es una persona capaz.
¿Cómo se están aplicando los seis principios tácticos para desarrollar el proyecto (ver recuadro a la izquierda)? Puede el encargado explicarlo claramente, utilizando un lenguaje normal o se escuda en el uso continuo de jerga?
Alguien cualificado debe poder dar respuestas directas y claras. El encargado de la construcción del sistema es, en realidad, el principal responsable de la ejecución del trabajo.
De él depende que el proyecto sea un éxito o un fracaso. Si es preciso, mejor conseguir otro.
¿Cuál es la situación esta semana?
Compruebe en directo el plan y el presupuesto del proyecto cada cierto tiempo. Obligue al encargado del proyecto a revisar el plan en vigor conjuntamente, que le explique cuánto dinero se ha gastado hasta la fecha e
