Los 4 factores de xito en un

proyecto de TI
En el mundo de TI (Tecnologas de la Informacin) el tema que a todos nos interesa
es Cmo tener un proyecto de xito?, para lo que primero debemos aclarar que
entendemos por xito en un proyecto de TI.

El xito de un proyecto de TI consiste en tener un proyecto a tiempo, en costo y

expectativas de ambas partes, con el cliente satisfecho por el alcance,
funcionalidad, servicio y el proveedor obtenga la remuneracin econmica
esperada, adems de recomendaciones, ms oportunidades de proyectos, prestigio,
aprendizaje, etc.

Habiendo definido previamente lo que nos gustara tener en un proyecto exitoso, lo

que sigue es definir qu es lo que requerimos para asegurar o al menos tener un
grado importante de certidumbre que sobreviviremos a todas los retos que implica
un proyecto de TI.

Para muchas empresas tanto clientes como consultoras definen el xito de un

proyecto en una buena administracin del mismo, lo que es decir, que un Project
Manager (certificado de preferencia) te puede ayudar a que tu proyecto tenga el fin
esperado pero oh! SORPRESA t proyecto sigue retrasndose (eso s, todo bien
controlado y notificado), tus costos se incrementan, la relacin cliente-proveedor
empieza a friccionarse y salvo que alguno ceda, terminar el proyecto con un final
inesperado, con usuarios finales molestos, insatisfechos y/o pagando un
presupuesto que no tenan contemplado para cubrir a medias sus necesidades, si te
suena familiar el caso, entonces debemos considerar los siguientes 4 factores que
desde antes de iniciar un proyecto de TI que te darn un nivel de certeza de que tu
proyecto ser todo un xito.

Los 4 factores tienen una secuencia, donde se van sentando los cimientos del
camino al xito de nuestro proyecto, en la medida que avancemos mostraremos la
dependencia de las acciones y decisiones de cada nivel con su respectivo nivel
previo.

Si alguno de los factores no cubre las bases esperadas, los factores siguientes (de
abajo hacia arriba) tendrn que superar las expectativas que compensen las
deficiencias de los anteriores de lo contrario nuestro proyecto puede estar
condenado al fracaso inclusive desde antes de iniciar el mismo.
Para esto definimos los 4 factores implicados en un proyecto de TI, que son la
negociacin, la tecnologa, la metodologa y los recursos.

1. Negociacin
La etapa de negociacin es la parte medular de un proyecto, desde aqu podrs
identificar rpidamente si tu proyecto tiene los argumentos para ser exitoso, o est
en riesgo el alcance y las expectativas de ambas partes.

Esta etapa la partimos en 2 importantes rubros, la negociacin interna del cliente

(usuario final) y la negociacin con el proveedor de servicios o el departamento de
TI.

a) Negociacin Interna

Esta negociacin suele ser la que define las directrices de todo lo involucrado en el
proyecto, donde se determina los 2 puntos claves de todo el proyecto, la duracin
pretendida y el presupuesto asignado al proyecto. Regularmente esta negociacin
se da por un intermediario interno de TI con el usuario final que regularmente no
conoce de TI

Para la duracin, es posible que este abierta a negociacin o que el usuario final
espere un plan de trabajo del proveedor, pero el primer punto en contra del xito de
tu proyecto es el caso ms comn, el proyecto debe estar tal fecha, no importa
cuando empieces, ni si estn los requerimientos mnimos para empezar a la
brevedad dicho proyecto.

Para el presupuesto, este puede ser aprobado de la manera tradicional, consigue al

menos 3 propuestas econmicas y la que nos convenza en costo beneficio esa ser
la indicada, lamentablemente el caso ms comn es seleccionar la propuesta ms
econmica (no necesariamente la mejor propuesta en alcance o beneficios) y
tomarla de base para negociar con los otros proveedores que pudieran tener una
mejor propuesta integral, esto puede terminar en 2 escenarios, una guerra de
precios entre los proveedores si el proyecto vale la pena, o que seleccionen la
propuesta ms econmica, con las implicaciones que veremos en los otros factores
de xito.

b) Negociacin Externa (para departamento de TI o proveedor externo)

Esta negociacin se da entre el intermediario con el usuario final y el departamento

de TI de la empresa o el proveedor de servicios de TI.

Esta etapa es donde el proveedor analiza los requerimientos del proyecto y hace
una estimacin de costo y tiempo, por diferentes factores es posible que los mismos
requerimientos difieran en precio y costo entre varios proveedores del servicio, es
aqu donde las limitantes si es que hay de tiempo y presupuesto para el proyecto
toman la mayor importancia.

En un escenario sano, el decidir por la mejor propuesta en costo-beneficio-tiempo

suele ser la ms acertada, lamentablemente el caso ms comn, es que tomen la
propuesta del proveedor que dijo 4 semanas cuando todos los dems al menos
dijeron 8 y el costo sea en esa proporcin o peor an, con tarifas mucho ms bajas.

Al finalizar esta etapa, ya puede influir de manera positiva o negativa en los otros
factores.

Recomendacin

Se debe analizar detalladamente el costo-beneficio del proyecto, ponderarlo en

valor de negocio y tomar la decisin en base a ello, si el proyecto est limitado por
el tiempo desde antes de empezar, est en riesgo el xito del proyecto, as como un
presupuesto limitado y no en valor del negocio ser otro riesgo adicional a tu
proyecto. Si el proyecto no aporta un valor tangible y medible es necesario
reconsiderar si debera de desarrollarse.

2. Tecnologa
Este factor es el siguiente en la secuencia del camino al xito de tu proyecto de TI,
Qu tecnologa hay que usar?

En primera instancia la seleccin de la tecnologa puede ser por los siguientes

factores

a) Costo (definido en la negociacin interna)

El costo cuando es una limitante, puede hacer que la tecnologa seleccionada

dependa de ello, por lo cual puede ser una tecnologa Open Source o una tecnologa
de renombre (donde las 2 son consideradas excelentes opciones, solo que hay que
considerar el impacto en los otros factores).

b) Infraestructura o polticas de la empresa

La infraestructura o polticas de la empresa definen que tecnologas deberan

usarse, muchas veces independientemente del tipo de proyecto

c) Propuesta del proveedor seleccionado

El proveedor seleccionado puede hacer una recomendacin de tecnologa que va en

funcin a su propuesta econmica, esto en determinados momentos podr marcar
una pauta importante en si no es una tecnologa estndar podr generar
dependencia por mucho tiempo con dicho proveedor.

Recomendacin

La seleccin de la tecnologa es el siguiente factor en importancia, ya que todo el

esfuerzo de desarrollo se har sobre cierta plataforma tecnolgica, para lo cual se
debe considerar lo siguiente: si no es altamente justificable no selecciones una
tecnologa de cierto nicho de mercado, es decir, existen infinidad de tecnologas,
pero segn tu ubicacin geogrfica o cultura tecnolgica de tu pas es posible que
sea difcil encontrar recursos de ciertos tipos de tecnologa, para lo cual podrs
generar una dependencia total con tu proveedor, adems que si llegaras a
encontrar apoyo en ese mismo nicho ser mucho ms caro que una tecnologa
estndar.

Aunque no es una regla escrita, si es claro que en las localidades y a nivel pas, se
adoptan afinidades con ciertas tecnologas para lo cual es fcil conseguir apoyo
para algunas, y para otras es necesario traer consultores de otras localidades o
pases con los costos que eso requiere.

Por decir un ejemplo, en Mexico, encontrar apoyo para aplicaciones .Net de

Microsoft es mucho ms fcil y econmico que encontrar el mismo apoyo para
tecnologas como JAVA, lo cual resulta que un consultor con conocimiento en JAVA
sea ms difcil de conseguir y obviamente ms caro, esto no indica que una
tecnologa sea mejor que otra, recomendamos el siguiente artculo de Salarios y
Factores.

3. Metodologa
Ya que decidimos las variables de presupuesto, tiempo y tecnologa, tendremos que
decidir que metodologa de trabajo tendremos que usar, esto debido a que segn
las caractersticas de nuestro proyecto podremos implementar de una u otra forma
de trabajo adecuada a cumplir las expectativas funcionales y de negocio esperadas.

Definimos brevemente metodologa, entendemos que son las reglas, polticas,

tcnicas y procedimientos para el seguimiento del desarrollo de un proyecto, para
esto existen muchas metodologas documentadas y en diferentes clasificaciones
(tradicionales, giles, etc.) y otras son adaptadas a cada empresa (propietarias,
pueden contener mezclas de metodologas).

Habiendo definido la metodologa nos enfrentamos a la dependencia de los

primeros 2 factores de la siguiente manera.

La negociacin de tiempo y presupuesto nos puede indicar el camino a seguir en la

seleccin de la metodologa, primero para adoptar una metodologa tradicional (RUP
por ejemplo) es necesario tener el tiempo y presupuesto adecuado, es decir, estas
implican un costo mayor en horas hombre en documentar, analizar y definir todos
los pasos de dicha metodologa, pero son recomendables en proyectos donde los
equipos de trabajo son grandes y los consultores cuentan con diversos perfiles y
niveles de conocimiento.

En proyectos donde el presupuesto y tiempo son pequeos (o muy castigados en la

negociacin) en relacin al alcance funcional del proyecto, se recomienda el uso de
metodologas giles y/o propietarias, las ltimas siempre y cuando estn orientadas
al resultado y no al plan.

Aunque la metodologa no tiene una dependencia con la tecnologa seleccionada, es

necesario aclarar que ciertas tecnologas se adaptan mejor a ciertas metodologas
de desarrollo, por decir los lenguaje orientados a objetos son ms fcilmente
modularizables y reciclables que la programacin estructurada.

Un punto importante por definir en este factor de xito, es si la metodologa es

orientada al resultado o al plan. Se dice que las metodologas giles son orientadas
al resultado, es decir, a software funcional, y no a actividades o tareas en cierto
tiempo, para esto se necesita una administracin de proyecto flexible, para lo cual
entendemos que nuestro plan de trabajo original puede sufrir cambios positivos o
negativos buscando siempre el resultado funcional. En el caso de metodologas
orientadas al plan, son conocidas las metodologas tradicionales como RUP, donde
existen tareas por desarrollar durante todas las etapas del proyecto, pero muchas
de ellas no entregan funcionalidad del software, solo los requerimientos de control y
documentacin definidos por la metodologa, estas regularmente no son tan
flexibles por estructura, para lo cual se tienen que hacer renegociaciones
intermedias si se detecta o requiere funcionalidad nueva no solicitada en fases
anteriores.
Recomendacin

La seleccin de la metodologa de trabajo es un factor importante en la bsqueda

de un proyecto de xito, para lo cual la seleccin de la metodologa debera ser de
la siguiente manera.

Debido a que tenemos dependencia directa o indirecta de los 2 factores inciales

que son la negociacin y la tecnologa, lo recomendable es seleccionar nuestra
metodologa de trabajo en base a lo siguiente: si el proyecto requiere un equipo de
trabajo grande debido a las etapas y dimensiones del proyecto, el uso de una
metodologa tradicional es lo ms recomendable, eso s, el costo y tiempo deben ser
proporcionales, en otro caso, nuestro proyecto antes de empezar ser un proyecto
con pocas probabilidades de xito.

Si nuestro proyecto puede ser desarrollado con equipos pequeos de trabajo, lo

recomendable es el uso de metodologas giles, ya que dichas metodologas estn
orientadas al resultado y no a las actividades, pero para que nuestro proyecto tenga
certidumbre de xito requiere que adems tenga una administracin flexible, es
decir el costo es menor a una metodologa tradicional, pero el tiempo puede ser
variable debido a la bsqueda del resultado final y no en base a una fecha de
terminacin donde no se consideren los imponderables.

4. Recursos
El ltimo factor del cual depende el xito de nuestro proyecto son los recursos que
estarn involucrados, es decir, las personas y sus respectivos perfiles de
conocimientos y experiencia en el tipo de proyecto, metodologa de trabajo y
tecnologa.

La asignacin de recursos a nuestro proyecto se puede dar de diferentes maneras,

iniciamos por la dependencia con cada factor previamente visto.

En la negociacin se define las 2 variables principales de nuestro proyecto, que son

el tiempo y el costo, esto determinara la cantidad de recursos que podremos
disponer para nuestro proyecto, y ms importante an ser el perfil y experiencia
que se pueda costear con el presupuesto asignado. En estos casos la formula
es sencilla, salvo que sea una estrategia comercial del proveedor (por ejemplo:
ganar un cliente, abrir mercado, etc.) :

el nivel y la cantidad de recursos asignados a nuestro proyecto ser

directamente proporcional al presupuesto de nuestro
proyecto, independientemente del tiempo que tengamos para dicho
proyecto.

Como vimos en los artculos previos, la seleccin de la tecnologa + el presupuesto

del proyecto, influirn positiva o negativamente en el perfil y experiencia de los
recursos asignados, es decir, hay ciertas tecnologas donde la oferta y la demanda
de dicho perfil tcnico determinaran los costos de los recursos, recomendamos el
siguiente artculo de Salarios y Factores. Si la tecnologa es de cierto nicho o muy
especializada, esto generar una dependencia durante mucho tiempo de nuestro
proveedor seleccionado, que posteriormente si acaso la tarifa inicial fue econmica,
ya existiendo la dependencia el proveedor podr renegociar tarifas nuevas en
etapas posteriores del proyecto.

En la metodologa seleccionada y su relacin con los recursos es como sigue, para

ciertas metodologas se requiere cierta cantidad y perfiles especiales de los
recursos involucrados, es decir se determinan responsabilidades y roles especiales
tanto como para administrar, controlar y desarrollar, para lo cual en muchos casos
es difcil que un recurso pueda cubrir varias funciones, por lo tanto ciertas
metodologas requieren diferentes perfiles de recursos durante las diferentes etapas
del proyecto, por decir un ejemplo, Project Manager, Software Architect, Data
Architect, DBA, Developer Senior, Developer Junior, Project Leader, Tester entre
otros.

Recomendacin

La seleccin de los recursos deber ser en funcin a los factores de negociacin,

tecnologa y metodologas, es decir, los perfiles y experiencia de los recursos,
debern ser los adecuados a nuestras variables del proyecto, si por alguna razn los
recursos no dominan la tecnologa, no tenemos los recursos suficientes para
cubrir el plan de trabajo en tiempo, asignamos juniors o practicantes (de manera
arbitraria) para reducir costos, nuestro proyecto estar muy limitado en sus
posibilidades de xito. Un caso comn es que algunas empresas prefieren tener una
mayor cantidad de recursos juniors practicantes que reduzcan costos y por
cantidad de recursos puedan tener el proyecto a tiempo, lamentablemente estos
casos son difcilmente ejemplos de xito, es posible que el proyecto se termine,
pero la calidad dejar mucho que desear y en muchos casos el re-trabajo costar
ms que hacerlo bien a la primera, donde aplica el conocido refrn lo barato, sale
caro.