Factores críticos

para el éxito

Gestión de
Proyectos de
Infraestructura
F actores críticos
F
para el éxito
¿Por qué fracasan los proyectos? Esta pregunta se la hacen todos y cada uno
de los que estudian las formas de encararlos o quienes tienen la
responsabilidad dirigirlos. La respuesta no es simple, por el contrario, un
proyecto que no pudo entregar la solución en tiempo y forma puede tener
causas muy complejas.

Los factores que atentan contra los proyectos pueden ser muchos y muy
variados, pero hay algo claro la responsabilidad de que se concreten de
manera exitosa o no será, en primer lugar de los directores, en su rol de
administradores del proyecto. Consecuentemente quienes ocupen estos
roles deben tener una actitud proactiva en forma permanente a fin de
encontrar aquellos aspectos que dificulten que el proyecto llegue a ser
exitoso.

Los factores o conceptos más importantes que se puede afectar de manera

negativa a un determinado proyecto son los siguientes:

El poder y la política: En general la estructura que se le asigna a modo de

soporte a un proyecto tiene una dependencia matricial con respecto el
administrador. El proyecto en sí mismo se nutre por un lado de personas
que conforman el Equipo de Trabajo específico y por personas que
pertenecen a otras áreas de la organización y que, por razones obvias,
reportan, formalmente, a otros líderes. Ejemplo de esto son las personas
que contratan personal, las que realizan las compras, las que confeccionan
los pagos a proveedores, etc.

Es por lo expuesto arriba que una de las realidades más fuertes que el
administrador de un proyecto le toca en suerte afrontar son las relaciones
con las estructuras matriciales con las que cuenta para encarar cada una de
las actividades que surgen de la planificación.

Todo proyecto, si bien tiene un equipo de trabajo exclusivo que va a realizar

las tareas específicas del mismo, tiene además conexión con las demás áreas
de la organización, las cuales van a reportar matricialmente a ese líder. Sobre
el equipo de trabajo el líder tiene autoridad formalmente constituida, sin

1
embargo sobre el resto de los cuadros no. Solo la capacidad política del
administrador será lo que permita saltar esas barreras.

La capacidad política entiéndase como la posibilidad de hacer, estrictamente

hablando el administrador del proyecto debe tener la capacidad y la
habilidad política para relacionarse con quienes tienen el “poder” y tienen
la posibilidad de influir sobre aquellos que harán que las directivas del
administrador sean respetadas por la estructura formal que no le reporta
directamente.

La capacidad de relación que ese administrador tenga con la totalidad de la

organización y el poder que detente para que las actividades fluyan de
manera correcta va a ser determinante a la hora pensar en un proyecto que
termine con éxito.

Identificación de las necesidades: muchas veces los proyectos producen

bienes o servicios que carecen de utilidad para los usuarios finales. Muchas
veces estos proyectos, que fueron definidos por la organización como un
ente abstracto, no estuvieron tuvieron en cuenta las necesidades de quienes
verdaderamente van a usar ese bien o servicio, lo cual puede llevar a un
fracaso, no porque no se haya cumplido en tiempo y forma con el desarrollo
sino porque no considero las necesidades de las personas.

Las causas de esto son muy variadas. No se hace un relevamiento correcto

de las necesidades, no se consulta al usuario final, no se da lugar a los
mandos medios para que sean ellos quienes especifiquen el proyecto.

Conocer al detalle las necesidades de aquellos a quienes está dirigido el

proyecto es fundamental, pues van a ser los que lo apoyarán de manera
incondicional.

Entender el juego de las variables: Quien administra debe comprender

cuales con las variables relevantes para el proyecto y tenerlas bajo control.

Existen distintos tipos de variables entre ellas las cuantitativas como el

tiempo, el dinero asignado y variables cualitativas como la calidad del
producto final, el ambiente de trabajo, la motivación del equipo de trabajo,
la idoneidad de los recursos humanos. Estas últimas son difíciles de medir y
la forma de hacerlos es a través de una medición indirecta sobre alguna
variable cuantitativa. Por ejemplo, la motivación de la gente puede llegar a
medirse por el tiempo que demanda la realización de una determinada
tarea.

La variable tiempo, cuantitativa por excelencia, es dependiente de muchas

otras, como la cantidad de recursos que se asignen, el equipamiento que se
use, la calidad del trabajo realizado. Esta última es una variable cualitativa y
el impacto que tiene sobre el tiempo deberá medirse en forma indirecta
como quejas de usuarios o errores detectados.

2
La elección adecuada de las variables a considerar como métricas del
proyecto es muy importante para poder gestionar el mismo.

La importancia de entender que variables medir y cuál es la relación entre

ellas, es para que el administrador pueda trabajar sobre cada una a fin de
modificar o corregir alguna de las variables claves como el tiempo.

Ejemplo: para poder acortar el tiempo de ejecución de una determinada

tarea el administrador tendrá que trabajar con algunas de las variables que
tengan una interdependencia con aquel tiempo, como dijimos arriba si
motivamos de manera diferente al grupo de trabajo quizás los tiempos de
ejecución se acorten mejorando por ejemplo las condiciones de trabajo o
pagando más horas extras. El administrador trabajo indirectamente sobre
el tiempo.

El equilibrio entre tiempo y resultado: Todo aquel que dirija un proyecto

deberá buscar el justo equilibrio entre el tiempo y el resultado. La
recomendación general es no considerar ninguna de las dos variables
totalmente dependiente o totalmente independiente una de la otra.

Hay reglas que intentan enmarcar esta relación a fin de que el administrador
las tenga muy en cuenta a la hora de llevar adelante un proyecto con éxito a
pesar de que pueda tener alguna demora en la ejecución del mismo. Estas
reglas son:

 fijado el tiempo máximo para entregar el proyecto tratar de

cumplirlo

 si por alguna causa no se pudiera llegar en tiempo, se debería llegar

a un acuerdo para acotar el resultado con el objetivo de presentar
algo concreto a la fecha establecida.

 cumplido el punto anterior, consensuar la nueva fecha de entrega de

los pendientes, sabiendo que no habrá más nuevas oportunidades.

Siempre es aconsejable y recomendable cumplir con los tiempos aunque sea

con un alcance limitado, pero si esto no fuera posible siempre hay que
presentar parcialmente lo que se tenga hecho y consensuar los pendientes
para una fecha cercana.

Manejo adecuado de las reuniones: Muchas organizaciones pasan gran

parte de su tiempo en reuniones interminables y totalmente improductivas.
Muchas veces el valor agregado que se saca de muchas de las reuniones a
las que concurren los equipos de trabajo son escasas o nulas.

Un factor clave de éxito es organizar todo lo relacionado a reuniones para

que las mismas se transformen en cortas y productivas.

3
Para que esto ocurra lo primero es distingue entre dos diferentes tipos de
reuniones:

 las informativas: se realizan con el objetivo de difundir y transmitir

información a la organización toda. No es necesario que concurra el
equipo de trabajo, solo el administrador con su equipo más cercano
de colaboradores debe asumir esta tarea ante la Alta Gerencia por
ejemplo.

 las de trabajo: estas reuniones están destinadas al estudio y

evaluación de un problema puntual. Requiere de todo el equipo de
trabajo abocado a la resolución de algún tema pendiente o la
modificación del plan producto de algún faltante de material. Por
ejemplo. Las reuniones de trabajo pueden ser lentas y largas.

La mayor recomendación sobre reuniones es que al fin de la misma se haga

una minuta o resumen donde consten todos los temas tratados y los
pendientes que se lleva cada equipo de trabajo. Los pendientes siempre
tienen que tener un responsable y un tiempo de resolución. Ninguno de los
pendientes que salga en la reunión tiene que cerrarse sin estas dos últimas
condiciones.

Entendiendo las comunicaciones: La dinámica del trabajo en equipo fijada

una meta es tratar de comunicarse con el objetivo de encaminar todos los
esfuerzos hacia un mismo lado. Planteado así el desafío más importante es
en cuanto a la “comunicación”.

El éxito de un proyecto pasa por comprender las conversaciones y entender

el concepto de. “hablar”, “escuchar” y entender el “trasfondo”.

Conversar no es solo la acción de hablar emitiendo un mensaje sonoro,

también se puede conversar o “hablar” utilizando otros medios como un
plan de trabajo, una directiva, unas acciones correctamente realizadas, etc.
En el hecho de conversar tanto o más importante que “hablar” es
“escuchar”, también por cualquier medio. Y cuando se escucha
obligatoriamente se debe tratar de entender el “trasfondo” que es la acción
de escuchar pero desde la profundidad del pensamiento de quien habla.

Entender el trasfondo cuando se escucha es entender al que habla.

Quien dirige o administra un proyecto tiene que aprender a “hablar” y a

“escuchar” y sobre todo a escuchar entendiendo el “trasfondo”. Esto es lo
mismo que decir quien administra debe prestar mucha atención a los
mensajes que da a los integrante del equipo de trabajo y al grupo de
proyecto en general y asegurarse que las personas escuchen lo que
realmente deban escuchar evitando por todos los medios malentendidos
que solo llevan a demoras o problemas innecesarios.

4
De igual modo debe saber escuchar al equipo de trabajo cuando es el propio
equipo quien se trata de comunicar con el administrador.

Caso de estudio: Operación

orientada a proyectos. AIM-2X

Planteo del problema

AIM es el nombre de fantasía de una empresa que se dedica a la venta
minorista (RETAIL) de productos de higiene personal y limpieza, la cual
encara un ambicioso proyecto de crecimiento de su capacidad operativa al
doble (2x) en un horizonte de 5 años.

Por el tipo de negocio el área de tecnologías de la información de AIM

deberá evolucionar de acuerdo al crecimiento esperado para el resto de las
áreas o proporcionalmente.

La gerencia general, al igual que la gerencia de sistemas e informática se

enfrentan con la problemática propia de un proyecto sin precedentes para
la organización.

Los temas que surgieron en una minuta de reunión previa al lanzamiento del
proyecto fueron:

 ¿Cómo manejar la expansión del área de TI, para que brinde soporte
al negocio, sin que ello implique duplicar o triplicar el personal
actual?

 ¿Cuáles son los procesos identificados como críticos, cómo se los

debería medir, cuáles son las competencias requeridas del equipo de
trabajo y cuál va a ser la organización que soporte dichas
competencias?

 ¿De qué manera la Gerencia General puede evaluar el

comportamiento del área de TI respecto del resto del negocio?

 ¿Cuáles deberían ser los Indicadores Clave de Performance que

mostraran objetivamente el comportamiento del área de TI?

5
La Solución
La gerencia general nombra como administrador del proyecto al gerente
producción que reunía algunas condiciones que lo hacía sobresalir de sus
pares:

 Poseía buenos conocimientos en tecnología pero no había

participado del área de TI de la compañía.
 Conocía detalladamente la organización.
 Estaba excelentemente considerado por sus pares y colaboradores
directo.
La gerencia general apostó a un líder carismático con buenos dotes de
comunicador y capaz de manejar para parte política entre áreas de la
organización de manera óptima.

El gran desafío y así lo entendieron todos, era mejorar en AIM el sector de

las Tecnología de Información, a fin de que sustentara el crecimiento del
negocio planteado.

La propuesta fue orientar la gerencia de TI completa hacia los proyectos.

Introducción: el contexto
La industria de la venta minorista es una de las más críticas en lo relacionado
a control de costos y velocidad de respuesta a nuevas oportunidades de
negocio y crecimiento. En estas organizaciones el Sector de Tecnologías de
la Información debe brindar sus respuestas al ritmo requerido por el negocio
o, de otra manera, se convierte en un obstáculo para el propio negocio. Los
sistemas de ventas minoristas exigen respuestas muy rápidas y sistemas
informáticos muy ágiles.

Resumen de AIM

Figura 6. Fuente: Elaboración propia.

6
Desarrollo
Como primera medida el nombrado administrador del proyecto (que a partir
de este momento se llamaría AIM-2X) convoca al Gerente General y al
Gerente de Tecnologías de Información con el objetivo de comenzar con la
definición del alcance del proyecto. En dicha reunión, se comienza a hablar
de un rediseño de los procesos y la re-organización de la Gerencia de TI,
preparándolos para acompañar a un crecimiento en puntos de venta que
los llevaría a prácticamente triplicar su volumen actual. La idea era pasar de
25 puntos de venta a 75, en el período de cinco años.

Metas
Las necesidades de la Gerencia General se podían resumir en los siguientes
puntos:

Escalabilidad: Desarrollar una organización que permita crecer junto con el

negocio.

Cumplimiento: Honrar los compromisos como rutina y no como excepción.

Esto fue ampliamente apoyado por todos.

Calidad: Incorporar procesos que garanticen la conformidad con la solución

final obtenida.

Costos: Desarrollar la conciencia de costos en el sector de TI.

Motivación: Evitar la rotación del personal de TI producto, entre otros, de

la sobrecarga de trabajo.

Visibilidad: Mejorar la inserción de la Gerencia de TI en el negocio haciendo

visible su performance.

Análisis del sector de TI encontrado

Habiendo el administrador tomado nota de las necesidades que surgieron
de la reunión con el Gerente General y el Gerente de TI, lo primero que hizo
fue realizar un pormenorizado análisis del sector de TI, encontrando lo
siguiente:

Fortalezas:

 Un equipo de trabajo integrado, posee gran sentido de pertenencia

a la organización, con un importante conocimiento funcional del
negocio.

 Una edad promedio adecuada para las distintas funciones.

 Buen nivel de capacitación, lo cual le daba una buena base para

planteos futuros

7
Debilidades / Oportunidades

Básicamente expresadas por las necesidades de la Gerencia General

expresadas en el punto anterior.

 Organización de TI con problemas de cumplimiento.

 Baja calidad en sus productos.

 Muy poca motivación en sus integrantes.

El usuario final no estaba incorporado al proceso de obtención de soluciones

de TI sino que éste esperaba que la misma le fuera provista. Si era de su
agrado o no, no se tenía en cuenta.

El reporte y la resolución de incidentes se efectuaban por varias vías

informales y normalmente el usuario final no era notificado de las soluciones
que se implementaban en respuesta a sus reclamos

Observaciones adicionales
La estructura organizativa encontrada era la típica funcional de una Gerencia
de TI: un área de Desarrollo, una de Soporte e Infraestructura y una de
Operaciones, dependiendo de ellas distintas funciones específicas de cada
sector.

Figura 7. Fuente: Elaboración propia.

8
Organización original del sector de TI
La organización de TI creció al ritmo del negocio, cubriendo la demanda de
nuevos trabajos e incorporando recursos. Siempre sobre la estructura
existente. En el día a día no fue posible analizar la efectividad del proceso
aplicado.

El método informal de trabajo aplicado no generaba motivación por la

indefinición de roles y responsabilidades que conlleva.

Los problemas encontrados dentro de la estructura de TI se podían resumir

en:

 Gran concentración de poder en la Jefatura del Área de Desarrollo.

 Actitudes heroicas en el personal, expresadas fundamentalmente en
trabajo adicional o fuera de hora.
 Atención a usuarios diseminada a lo largo de toda la estructura. No
había una única puerta de entrada de reclamos.
 Diversidad de criterios para planificar, desarrollar y controlar las
actividades, dependiendo exclusivamente de la persona
responsable.
 Tareas de soporte y mesa de ayuda, interrumpiendo las actividades
normales de los especialistas, con los problemas que ello acarrea
tanto para la persona interrumpida, como para el proyecto.
 Incorporación tardía en el desarrollo de las soluciones de los diversos
grupos como Soporte y Operaciones.
 Carencia de indicadores objetivos de la performance del sector.
Las oportunidades existentes
La necesidad de soportar el crecimiento y los diversos inconvenientes
percibidos por la Empresa y el personal de TI para prestar el servicio
requerido permitió entonces plantear los siguientes frentes de trabajo:

Negocio: Mejorar el cumplimiento e integrarse totalmente al negocio.

Focalizarse en la gente: Aprovechar el capital humano existente y motivarlos

con un proyecto desafiante.

Apuntar a la excelencia: Formalizar el concepto de calidad y establecer

estándares de excelencia.

Estructura organizativa: Definir la estructura en base a los procesos se

definan y no adecuar los procesos a la estructura.

9
Propuesta de solución
Se identificaron los procesos de creación de valor:

Figura 8. Fuente: Elaboración propia.

Procesos
 Estos pueden resumirse en:

 Proceso de atención al negocio

 Proceso de desarrollo de soluciones

 Proceso de soporte al servicio

Se identificaron además los procesos de soporte correspondientes.

10
Indicadores
Se definieron para cada proceso de valor sus correspondientes indicadores
así como los roles responsables de producirlos.

Proceso de atención al negocio: Indicadores de satisfacción del usuario final,

estado de los requerimientos e innovaciones aportadas al negocio.
Responsabilidad de la Producción del Indicador: Gerencia de Producto.

Proceso de desarrollo de soluciones: Indicadores de proyectos en cartera,

proyectos iniciados, proyectos terminados y otros estados de proyecto.
Información de desvíos y análisis de los mismos. Responsabilidad de la
Producción del Indicador: Jefe de la Oficina de Proyectos.

Proceso de soporte al servicio: Indicadores de utilización del Help Desk,

tiempos de solución. Responsabilidad de la Producción del Indicador: Jefe
del Sector de Soporte.

En cada caso para cada indicador se definieron valores objetivos y situación

respecto a esos valores.

Diseño organizativo
En base a estos procesos, se redefinió la estructura organizativa derivando
en los siguientes sectores (Ver Figura 9). Se definió una estructura matricial
que fuera capaz de soportar el desarrollo de proyectos usando los recursos
de la gerencia.

Los sectores que se definieron dentro de la estructura de TI fueron los

siguientes:

Sector de Responsables de Producto (PM)

 Sector oficina de proyectos (PMO)

 Sector de desarrollo

 Sector de calidad (QA)

 Sector de soporte

 Sector de operaciones

11
Figura 9. Fuente: Elaboración propia.

La relación Proceso-Organización Responsable es la siguiente:

 Proceso de atención al negocio

Sector de responsables de producto

 Proceso de desarrollo de soluciones

Sector oficina de proyectos

Sector de desarrollo

Sector de calidad

 Proceso de soporte al servicio

Sector de soporte

Sector de operaciones

12
Justificación de la propuesta efectuada
Para el Proceso de Desarrollo de Soluciones, y la implementación del Sector
Oficina de Proyectos, objeto de este trabajo, el análisis de la situación
existente nos llevó a algunas de las siguientes conclusiones.

 La incorporación del concepto de proyecto para soportar al Proceso

de Desarrollo de Soluciones ayudaría a formalizar compromisos de
objetivos, responsables, tiempos y recursos.

 La propuesta de creación de un Equipo de Proyecto con roles y

responsabilidades definidos para cada uno de sus integrantes
colaboraría con nuestro objetivo de mejorar la motivación y ayudaría
a iniciativas de plan de carrera, competencias, etc.

Figura 10. Fuente: Elaboración propia.

Ejemplo de equipo de proyecto

 La concentración de responsabilidad sobre los proyectos en un
sector, la Oficina de Proyectos, nos permitiría trabajar sobre una de
las debilidades principales de la organización anterior, el
cumplimiento de la demanda insatisfecha, pudiendo obtener
indicadores precisos acerca de este tema.

 La organización resultaría ser más flexible en cuanto a la cantidad de

recursos, aprovechamiento, tipo y modalidad de adquisición de los

13
 mismos que se requiere, en función a la cartera de proyectos que se
está administrando. Esto permitiría ampliarse o contraerse, dentro
de ciertos límites, en la estructura operativa en función a la
demanda.

 El diseño organizativo seleccionado fue el de la Oficina de Proyectos

(PMO) tipo Gerente, integrada por un Jefe de Oficina de Proyectos,
quien tenía la responsabilidad por el Sector y la Cartera de Proyectos,
así como de producir los indicadores del proceso de Desarrollo de
Soluciones.

 Los Jefes de Producto, en función a la demanda, generan la Cartera

de Proyectos. Los proyectos una vez aprobados para su ejecución
entran en el área de responsabilidad de la Oficina de Proyectos.

Ubicación en la organización del rol de jefe de proyecto

Se decidió ubicar el rol de Jefe de Proyecto, dentro de la estructura de la
Oficina de Proyectos en lugar de pertenecer a otro Sector.

La resultante de esto es:

 La oficina de proyectos provee el rol de jefe de proyecto.

 Los jefes de proyecto dependen jerárquicamente del jefe de la

oficina de proyectos.

 El equipo de trabajo depende jerárquicamente del jefe de proyecto

durante la ejecución del mismo.

Tratamiento del mantenimiento y evolución de las soluciones

existentes
Los mantenimientos a la plataforma de soluciones existentes, también fue
encarada como proyecto con un presupuesto periódico y equipo designados
para la resolución de los cambios requeridos.

Los criterios que se tomaron para seleccionar la Oficina de Proyectos Tipo

Gerente fueron:

 La organización en su conjunto no tenía incorporada la cultura de

proyecto en su modalidad de operación, el desarrollo de una
concentradora de la responsabilidad que proveyera además la
competencia de Jefe de proyecto, se encontró adecuada para una
rápida difusión y asimilación por parte de la organización completa.
El cambio no fue resistido.

 Los jefes de proyectos se incorporaron a la Oficina de Proyectos,

dependiendo del Responsable del Sector.

14
  La organización del mantenimiento de aplicaciones como proyectos:
esta decisión se fundamentó en la idea de evitar áreas marginadas,
dedicadas a mantener productos obsoletos y que se rigieran por sus
propias reglas organizativas y métodos de trabajo. La organización
de proyecto extendida a estas tareas permitió aplicar el concepto de
equipo de trabajo y métodos de trabajo similares al resto de las áreas
e incorporar la idea de versión de los productos. Con el concepto de
versiones evitamos también la idea del mantenimiento como un
trabajo continuo.

La puesta en marcha de la mejora

Lo expresado hasta aquí respecto de los nuevos procesos y los cambios
organizativos fue puesto en marcha en forma gradual a medida que
transcurrió el proyecto.

La oficina de proyectos comenzó a operar de acuerdo a la modalidad

prevista una vez concluida la definición de roles y responsabilidades de las
áreas y la necesaria capacitación de sus primeros integrantes.

Los indicadores de performance de los procesos se produjeron por los

responsables previstos en el diseño de los procesos.

Se efectuaron ajustes al planteo original, consolidando varios de los

procesos de soporte en función a lo demostrado por la operación del nuevo
modelo.

Se siguieron junto con el personal de la empresa varios proyectos operando

de acuerdo al nuevo modelo, transfiriendo totalmente la responsabilidad de
la mejora al Equipo de Mejora interno del Cliente, quien continuó luego en
una modalidad de mejora continua.

Se planificaron evaluaciones periódicas, la primera a los seis meses de

entregado el Proyecto y el resto en forma anual.

Lecciones aprendidas
 El cliente demanda soluciones completas sin interesarle la división
funcional dentro de TI por lo cual el enfoque de procesos es el
adecuado para resolver esta necesidad.

 Como todo proceso de mejora debe existir la necesidad para hacerlo

y esta debe estar fundada en urgencias y razones de negocio.

15
 El sponsor del proyecto de mejora debe ser quien escuche las quejas
del negocio respecto al área que se quiera mejorar.

 El cambio cultural que implica para una organización funcional la

incorporación de procesos orientados a la operación por proyectos
no debe ser minimizado.

 Debe adecuarse el sistema de recompensas para promover,

incentivar y reconocer aquellos miembros de la Organización que
logran los objetivos planteados por el nuevo modelo de procesos
propuesto y no incentivar viejas costumbres, útiles en otras
estructuras pero nocivas en la nueva modalidad de operación.

 La búsqueda y producción de indicadores de los procesos de valor es

crítica. Estos deben ser mantenidos en el mínimo número posible y
deben ser presentados en forma regular a la Dirección luego de
concluido el proceso de mejora para analizar la evolución de la
misma.

 Normalmente la implementación de este tipo de procesos se da en

un momento adecuado en que el negocio lo requiere, la Dirección
está dispuesta a respaldar un cambio importante tanto en lo político
como en lo económico, y el Sector objeto del cambio está dispuesto
a experimentar un nuevo modelo de trabajo. Debido a que la
combinación de estos factores no es muy común, no debe
desperdiciarse una oportunidad de este tipo efectuando
simplemente cambios cosméticos.

 Los conflictos de poder generados por las estructuras que se

cambian, no deben ser reemplazados por otros en la nueva
estructura. Esto debe ser tenido en cuenta desde el comienzo como
un riesgo y monitorearlo continuamente.

 La adecuación, vía selección y capacitación, de los roles a las nuevas

estructuras debe ser hecha en forma simultánea con la creación de
estas.

 Como todo cambio importante, una vez consensuada una dirección,

esta debe ser seguida sin admitir discusiones ni retrocesos. La
práctica de la ejecución demostrará los detalles que necesitan ser
ajustados.

16
Conclusiones/ Resultados
 El proyecto se comenzó y se terminó dentro de las fechas fijadas. En
dos años se logró la implementación planificada originalmente.

 El éxito del proyecto fue tal que al cabo de los 5 años, AIM contaba
con 225 puntos de ventas. (El objetivo original eran 75).

 El administrador del proyecto original se dedicó a rediseñar el área

de IT a partir del cual surgieron los proyectos que contribuyeron con
el negocio y permitieron a la compañía crecer.

 El gran despegue que logro AIM se debió fundamentalmente al

rediseño que lograron en el Área de las Tecnologías de la
Información.

 Al cabo de los 5 años la facturación llego a los U$S 1000 millones de

dólares.

 AIM cumplió con no duplicar su personal y trabajaron con un

indicador que relacionaba a la cantidad de personal con la
facturación, esto le permitía incorporar personal cuando se
incrementaba la facturación.

 AIM que arranco teniendo presencia solo en Latinoamérica paso a

tener presencia en EEUU y Europa a través del comercio electrónico.

 Logró una excelente escalabilidad en su Área de Tecnologías de la

Información lo cual le permitió incursionar en otros mercados.

17
Bibliografías de referencia
Chinkes E. y Oriolo C. (2004). Administración de proyectos de tecnología de la
información. Buenos Aires. Argentina: Cooperativas.

Laudon, K. y Laudon, J. (2004). Sistemas de Información Gerencial. (8va Edición).

D.F. México: Pearson Educación.

Ramírez L. (2005). Gestión del desarrollo de sistemas de comunicación e

informáticos. Madrid. España: Thomson Editores Spain, Paraninfo S.A.

18