Proyectos de Tecnología Informática.

No permita que sus proyectos de tecnología informática terminen costando y

durando mucho más de lo necesario. Relacionamos los factores que por lo general
se omiten en la planeación y son críticos para el éxito de los proyectos.

Por lo general lo que se comenta (como me lo comentó un cliente una vez), los proyectos de
tecnología informática siempre demoran y cuestan mucho más de lo que originalmente estaba
presupuestado, y sin los resultados fijados desde el principio. El símil fue que así como uno
solicita tres cotizaciones, en vez de seleccionar una en cuanto a tiempo y costo habría que
sumarlas.

Los proyectos de tecnología informática tienen múltiples componentes o subproyectos que de

no ser bien identificados, y sobre todo asignados a su responsable, hacen efectivamente que la
duración y el costo del mismo sean mucho mayores al planteado, si es que se logran los
objetivos de funcionalidad y servicio inicialmente estipulado. Ahora se ha facilitado un poco
más la ejecución de este tipo de proyectos dado que las casas de software (SAP, Oracle,
JDEdwards, entre otras) han optado por ofrecer esquemas de implementación "aceleradas", es
decir, en vez de tomarse los 18 a 24 meses que tomaba la implementación de una solución
básica, han resuelto muchas de las variables en el proceso de implementación y han elaborado
procesos de implementación de aproximadamente entre 4 y 6 meses. Sin embargo, hay que
leer minuciosamente a qué se compromete el/los proveedores y a qué se compromete uno
como cliente.

Por lo general, uno podría contratar los equipos, su instalación, la instalación del sistema
operativo, el montaje de las aplicaciones, la capacitación al usuario final y a los funcionarios
del área técnica en su operación y administración. Sin embargo hay responsabilidades
exclusivas del cliente como son el rediseño de procesos, los procesos de migración,
convivencia, limpieza de datos, definición y ejecución de perfiles de seguridad, definición de
pruebas de aplicaciones, y muchos otros que de solo enumerarlos acabaríamos con el espacio.

Hay algunos puntos álgidos cuando se implementan los proyectos de tecnología, y

normalmente tienen que ver con la disponibilidad de tiempo de los usuarios. El proveedor
pretenderá que haya un grupo de personas asignados de tiempo completo al proyecto, más si
se tiene afán, sin embargo, en esta época, la designación de personas especiales para dejar sus
puestos y dedicárselos exclusivamente a un proyecto por cuatro o seis meses es casi un
imposible. Se debe entonces ser muy celoso en la elaboración de los cronogramas y en
especial en la asignación del recurso humano del cliente. Por lo general el recurso humano del
proveedor viene definido e incluido dentro de los cronogramas iniciales, pero casi siempre se
omite hacer, por ejemplo, un balanceo de cargas para los recursos del cliente.

Otro aspecto crucial tiene que ver con la cantidad de modificaciones que se aceptará se hagan
a las aplicaciones. En las implementaciones "aceleradas" éstas están prácticamente abolidas,
ya que el proceso de definición del requerimiento, programación, prueba y aceptación es
bastante largo y ocasionaría fuertes retrasos en la ejecución del proyecto. Hay que ser muy
claros tanto con el proveedor como con los usuarios de hasta donde abarca el proyecto. El
factor más importante es tener en cuenta qué pierden los usuarios con la implementación del
nuevo sistema (siempre sabemos lo que ganan, pero desconocemos lo que dejarán de tener) y
a estas falencias habrá que buscarles una solución bien sea con el proveedor directamente, o
con medidas alternas, pero siempre buscando satisfacer esa necesidad (mas no los caprichos)
del usuario. La definición clara de el alcance en materia de modificaciones es crucial tanto para
el desarrollo del proyecto, como para la contratación posterior de mantenimiento sobre las
aplicaciones (si se contratan externamente). Cuando el desarrollo de aplicaciones es interno,
es importante poder definir el proyecto en diferentes etapas marcadas por bloques de
funcionalidad e ir terminando cada etapa por versiones de la aplicación, como si fuera una
casa de software, pero esto es tema por completo de otro artículo.

Se pretende, con la implementación de un nuevo sistema, hacer las cosas más fáciles para la
empresa y los usuarios. Sin embargo, si se omite una revisión a los procesos y procedimientos
actuales, es factible que en el momento de poner en producción el sistema se tropiece con
obstáculos operativos que habrá que resolver en la mitad del cambio, momento que no es
propicio para hacerlo. Dentro de las actividades del proyecto, a cargo del cliente, estará la
evaluación de los procedimientos y procesos actuales a la luz del nuevo sistema, y el diseño
y/o ajuste de los procesos actuales a la aplicación. La programación de estos ajustes debe ir de
la mano con la programación de la implementación e idealmente, al tiempo con la
capacitación en el uso de la aplicación al usuario final, se imparte la capacitación
procedimental.

Por último, no descuide dos procesos que tienen que ver con la información actual: el de
convivencia y el de migración. El primero es el que le permitirá tener dos sistemas (el viejo y e
nuevo) operando en simultánea durante unos meses. Por ejemplo, es probable que esté
facturando con el nuevo sistema, pero que la contabilidad esté todavía en el viejo, o que en el
nuevo sistema tenga ya lista la contabilidad pero los auxiliares estén en el viejo. La decisión
sobre la puesta en producción de las aplicaciones y su orden está estrechamente ligada a
decisiones sobre conveniencias en esta etapa de convivencia.

La migración compete al traslado de la información corriente e histórica en los sistemas

actuales al nuevo. Hay consideraciones de tipo tributaria, otra de tipo comercial y de
producción. Si en el trasteo se pierde algo porque en el nuevo sistema no hay como manejar
ese tipo de información, es imperante establecer un esquema de acceso a la información
antigua. Como recomendación, limpie la información antes de migrarla, en especial en
archivos como de clientes y de proveedores donde la información se incluye la primera vez que
se tiene contacto con el cliente y/o proveedor pero no se vuelve a actualizar.

Los proyectos de tecnología informática no necesariamente tienen que durar o costar más de
lo inicialmente pactado. Si el alcance descrito desde el inicio de la contratación es el que se
ajusta a las necesidades del plan estratégico de la compañía y al plan estratégico de tecnología
informática, si la contratación se hace acorde a las necesidades de éxito del proyecto y no de
protección jurídica, y si la ejecución tiene en cuenta recomendaciones como las que
brevemente referimos arriba, el éxito estará garantizado.
Priorizando Proyectos
Ejecutar proyectos tiene no una sino hasta dos y tres metodologías, pero definir las
prioridades de los mismos, no ha corrido con la misma suerte. Algunas pautas para
priorizar sus proyectos.

Los proyectos existen desde siempre, pero recientemente se ha ido

construyendo esquemas de trabajo que permiten que los proyectos sean
efectivos y cumplan con su propósito.

Ya no es solo terminar el proyecto dentro del tiempo y costo asignado

sino también producir el “entregable” con el cual quien lo recibe obtendrá los beneficios
estipulados desde la justificación del mismo.

Se han generado dos metodologías claras, una avalada e impulsada por el PMI, quien
produce el PMBok (cuerpo de conocimiento de proyectos) y otra, conocida como
PRINCE2, generada por la Oficina de Comercio Gubernamental en el Reino Unido,
inicialmente para proyectos de TIC y ahora para todo tipo de proyectos. Está tan de
“moda” las metodologías de proyectos que la ISO está preparando el estándar ISO21500
que reúne, según los preliminares, las dos metodologías enunciadas arriba.

A pesar de todo este trabajo, no existe una propuesta concreta para priorizar proyectos.
Existen todo tipo de recomendaciones sobre diferentes alcances para lograr esta
priorización, pero se quedan cortos en cuanto a definir una serie de pasos para definir
prioridades, no porque no se quiera, sino por lo difícil que es conjugar los diferentes
requerimientos que tendría esta priorización.

Cuando se clasifica algo, lo que sea, por razones obvias quedaran unas en los primeros
lugares y otras en los últimos lugares. Igual sucederá con cualquier método que se
utilice para proirizar proyectos. Lo importante no termina siendo solo el orden, sino que
todos los involucrados estén de acuerdo con el resultado obtenido, tanto los que
defienden los proyectos en los primeros lugares, que de seguro se llevarán a cabo, y
para quienes los proyectos tendrán que esperar otra ronda, por no haber clasificado lo
suficientemente alto.

Para lograr esta aceptación, los criterios de clasificación deben ser acordados entre
todos, y tener un claro reflejo en el beneficio para el conjunto, no en forma individual.
Un conjunto de criterios que ha tenido buen resultado en nuestra práctica incluye:

Impacto Estratégico: ¿Qué tanto impactará el proyecto al logro de los resultados

estratégicos de la compañía Existen herramientas que permiten evaluar y medir el
impacto estratégico de los procesos y la información, en forma numérica, asignando
valor al impacto que se perciba sobre la necesidad o no de un proceso para la correcta
ejecución de la estrategia.

Beneficio: ¿Cuál será el monto del beneficio a obtener al aplicar el producto del
proyecto? Debe ser claro que el beneficio debe estar dado por el receptor del producto
del proyecto, beneficio sobre el cual se hicieron las justificaciones para el proyecto. Es
importante de todas maneras que el beneficio se logre, y esto solo se podrá determinar al
finalizar el proyecto y aplicar el producto del mismo.

Esta es una de las variables sobre las cuales se puede hacer análisis de sensibilidad para
tratar de “limpiar” cualquier sesgo que pueda tener la información inicial. A mayor
beneficio, mayor calificación para el posicionamiento del proyecto. Se pueden estipular
rangos de beneficio, que debe ser de cualquier manera traducido en beneficios
económicos (a menos que sean proyectos que se deben emprender por requerimientos
legales, los cuales tienen prioridad alta de todas maneras).

Factor de Éxito (que podría también ser una medida del riesgo): ¿Qué tan factible es
tener éxito, no solo en la ejecución del proyecto sino en el logro de los beneficios? Por
definición, el análisis de riesgo involucra análisis de probabilidades de que el riesgo
suceda, y la capacidad para mitigarlo. A mayor riesgo, menor probabilidad de éxito, por
lo tanto debería tener una calificación menor que un proyecto con menos riesgo.

De la calificación de cada uno de estos criterios, habrá posibilidades de darles pesos en

varias alternativas, o de multiplicarlos entre sí para luego generar un gran total.

De cualquier manera, cada empresa requerirá estructurar su propio sistema de

priorización de proyectos, y ojalá terminarlos antes de que los criterios de clasificación
cambien su prioridad.

 
Alcance de un Proyecto

No se aventure a desarrollar proyectos y avanzar en el tiempo hasta que no tenga una

claridad suficiente sobre lo que se espera que haga; defina bien el alcance antes de
distraer recursos.

Hace unos años no teníamos metodologías que permitieran

indicar las mejores prácticas para llevar a cabo un proyecto y
garantizar el cumplimiento de sus objetivos con el uso de los
recursos asignados al mismo.  Hoy contamos con el cuerpo de
conocimiento sobre estas mejores prácticas en un documento que
se conoce como el PMBok (Project Management Body of
Knowledge).

La teoría indica que lo primero que se debe estructurar, aparte de unos documentos
formales de establecimiento y lanzamiento, es el alcance del proyecto.  Se debe llegar a
un claro entendimiento entre el cliente y el proveedor (quien recibirá el “producto” del
proyecto y quien desarrollará actividades para elaborar el “producto” del proyecto.)

Por lo general el cliente va a querer que haya la menor definición posible para poder
cambiar el alcance, y el proveedor querrá el mayor nivel de definición para evitar
desfases y reducir el riesgo de imprevistos.  Este balance es difícil de lograr en la
medida que el cliente no quiera concretar lo que necesita, y que el proveedor no pueda
manejar la incertidumbre.

Es necesario entonces un proceso de negociación que permita definir no solo el alcance

sino el mecanismo para manejo del alcance.  Una de las mejores herramientas para esta
tarea es precisamente la construcción de la estructura de desglose de trabajo (EDT, o
WBS del inglés Work Breakdown Structure).

Desarrollar la estructura de desglose de trabajo bajo la metodología propuesta invita a

descomponer el o los productos finales en componentes y cada componente en sub-
componentes hasta que no se puedan hacer más divisiones.  Es importante recordar que
seguimos hablando del QUE, es decir del alcance, no del COMO que vendrían a ser las
actividades.

Cada elemento,  cada componente de esta estructura, debe tener definido un alcance,
que permita determinar que se ha logrado el objetivo.  Cada elemento “madre” o que
tenga sub-componentes se deberá construir a partir de los elementos debajo de él, y no
con trabajo adicional.  Son principios sencillos pero por nuestra característica occidental
de concentrarnos en el cómo, omitimos desde el principio.
Tenemos claro que la vida real no responde a procesos perfectos, ni se puede encajar en
una metodología rígida.  Pero por lo menos debemos tener claridad en buena parte del
contenido de esta EDT, y en especial en aquellos elementos que su variabilidad pueda
ocasionar un desvío grande en el desarrollo del proyecto.  Cualquier omisión en este
aspecto puede por si sola llevar al fracaso el proyecto, por pequeño que sea.

En la medida que el equipo humano del proyecto es más numeroso, y que su ubicación
geográfica pueda ser dispersa, con mayor razón se hace indispensable tener una
definición clara del alcance, de ese objetivo a donde debemos llegar, para que cada
miembro del equipo pueda tener su norte establecido y determinar las actividades a
desarrollar bajo su responsabilidad que le permitan lograr los entregables a su cargo.

Por alguna razón que no logro identificar, la mayoría de proyectos que planeábamos (si
a eso que hacíamos se le podía llamar planear) siempre iniciaba con una lista de
actividades y sub actividades, seguidas de la asignación de tiempos a las mismas,
responsables, y en ocasiones hasta los recursos requeridos para desarrollar las
actividades.  ¿Y el alcance? De eso no sabíamos mucho. 

Ahora tenemos las herramientas que nos permiten sugerir que hasta que la WBS no esté
definida, en buena parte todos sus entregables, tendremos un alto riesgo de incumplir,
no porque no seamos capaces de hacer lo que se nos encomiende, sino porque el norte,
además de no estar claro, puede ser sujeto a variaciones.  ¡No arranque a hacer hasta que
no termine de planear el que!

¿Se lo permitirán las restricciones de tiempo del proyecto? ¿Se lo permitirá su cliente?
De usted depende manifestar los beneficios de planear el alcance, para garantizar que
durante el hacer haya claridad en el curso de acción además de mayor certeza en el
cumplimiento.
Fracaso en los proyectos informáticos

Post de Gestión Proyectos on Enero 06, 2010 by Jose Luis Perez Garcia

Fuente: www.galorath.com  - Software Project Failure Costs Billions.. Better

Estimation & Planning Can Help

Se continúa fracasando en la ejecución de proyectos informáticos al igual que en el

pasado. Creo que es un hecho rotundo y me da la impresión que ninguno de nosotros
somos capaces de aprender de los fracasos.

Me quedo con algunos datos de este interesante estudio de la ejecución de proyectos

informáticos

Standish Chaos Reports:  Standish is probably the most referenced.  They define
success as projects on budget, of cost, and with expected functionality.  There are
several updates to the Standish “Chaos” reports.  The 2004 report shows:

 Failed Projects: 18%

 Challenged Projects:  53%
 Successful Projects: 29%
 Canceled projects cost $55 Billion Annually?

Los datos son realmente terroríficos. Un 18% de proyectos fallidos, es decir que nunca
se han puesto en marcha. Un 53% que se han puesto en marcha pero con menos
funcionalidades de las esperadas y además fuera de tiempo. Solo un 29% de los
proyectos se entrega en tiempo y con las funcionalidades esperadas.

Más estadísticas que han de provocar una seria reflexión entre todos los que nos
dedicamos a la informática:

Dynamic Markets Limited 2007

Se realizaron encuestas a 800 managers de proyectos en 8 países:

 62% de proyectos entregó el sistema fuera de plazos

 49% de los proyectos tuvieron desvíos presupuestarios
 47% de los proyectos con costes de mantenimiento mayores a los planificados.
 Más del 25% de los proyectos fueron cancelados

Un estudio de Gartner entre proyectos realizados en diferentes empresas revela que las
tareas de testing consumen entre un 25% y un 50% del tiempo total del ciclo de vida
del sistema. A pesar de la importancia del hecho las organizaciones siguen opinando
que no aporta ningún valor al negocio.

Otro estudio de Info-Tech Research Group revela que sólo el 11% de las
organizaciones ven a la tecnología como un arma estratégica.
Algo sigue sin funcionar bien. Parecía que después de la crisis del software nos
habíamos concienciado para hacer las cosas bien pero las evidencias revelan justo todo
lo contrario.

¿Quienes son los culpables?

En mi modesta opinión lo somos todos. Creo que existen muchas causas, iré
enumerando las que considero más importantes aunque no tiene porque ser por orden de
importancia.

 Fallos de comunicación: Gran defecto de una gran parte de los informáticos,

sobre todo los más jóvenes.
 Falta de implicación de los usuarios funcionales : Es importante implicar a los
usuarios funcionales de la organización, gestionar el cambio que va a suponer
para ellos la implantación de la tecnología.
 Falta de implicación / desmotivación del equipo de trabajo: Peligroso si no lo
detectamos a tiempo, es importante crear un grupo y trabajar como tal. Es muy
importante la gestión de la carrera de los miembros del equipo ayudarles a crecer
profesionalmente y con temas que los motiven. No siempre es fácil conseguirlo.
 Falta de recursos suficientes o falta de preparación/cualificación de los
disponibles: Los que hemos trabajado o trabajamos para empresas de consultoría
sabemos de qué estamos hablando ¿verdad?
 Expectativas irreales del cliente: En plazos, en interfície de usuario.
 Plannings políticos impuestos por el cliente: Fechas emblemáticas,
inaguraciones,etc. ¡Claro!. Pretenden siempre poner en marcha para ese día y
que el proyecto se implante en tres meses.
 Presiones comerciales en el caso de consultoría : Últimamente parece ser que el
único valor que aportan las consultoras hoy en día es el bajo precio porque los
compradores presionan para reducir sus costes en proveedores informáticos.
Recientemente cierto grupo bancario impuso a todos sus proveedores una rebaja
unilateral del 30% en sus tarifas y quien no esté de acuerdo deja de trabajar.
 Presiones presupuestarias en el caso de proyectos internos : Siempre hacer
mucho más con menos.
 Plannings irreales: Gente que vive en un mundo Walt Disney y minusvalora la
dificultad de los proyectos. Deberían empezar a trabajar utilizando PERT para
sus planificaciones.
 Gestión de riesgos inexistente: ¿Riesgos? ¿Qué riesgos?. Como hables de
riesgos en más de un cliente te van a tildar de catastrofista y pedirán tu cabeza al
comenzar el proyecto. Es algo complejo introducir una gestión de riesgos
honesta en un país que tiene que mejorar tanto como España.
 Gestión de cambios / alcance del proyecto: Esto es el eterno problema.
Requerimientos crecientes y a implantar dentro de los mismos plazos y con el
mismo presupuesto, si un manager no controla cada petición nueva que está
fuera del alcance y la presupuesta asignándole un precio y una fecha de
implantación está completamente perdido. Ni que decir tiene que siempre
tenemos la presión del comercial de turno de la empresa para que el cliente esté
contento.¿Verdad que si encargamos una casa y de repente le pedimos cuando
 está a mitad de construir que nos pongan un jacuzzi nos lo cobrarán? ¡Pues
intentar aplicar la misma filosofía!
 Nefasta gestión comercial: Existe una competencia desleal entre todas las
empresas que se dedican a la informática en España y eso sólo provoca una baja
de la calidad. Plazos apretados, equipos con menos experiencia de la requerida,
planificación hecha por los comerciales. En el 99,99% de las veces siempre tiene
el mismo final la película. Proyecto de héroes que acaban el proyecto fuera de
tiempo entregando parte de su vida para terminarlo.

¿Cómo podemos arreglar todo esto? ¿Lo podemos arreglar?

Sinceramente no lo se pero en mi opinión mientras que las consultoras continuen

"disparándose a los pies" será complicado. En otros sectores hay colegios profesionales
serios que fijan unos mínimos de calidad que hacen menos penoso el trabajo diario y
expulsan a los negligentes de la profesión. En la informática y en España no estoy
seguro si algún día se conseguir