2. GESTIÓN DE PROYECTOS
Proyecto TIC
Fases
Acciones a
desarrollar
Personas
Involucradas
Responsables
de su
ejecución
Tiempos
estimados
Sieber (2006)

3. Proyectos TIC
Distintas
metodologías y
herramientas de
gestión de
Proyectos
Facilitar las
tareas de
definición de los
objetivos como
el Alcance del
proyecto
Coordinación y
seguimiento
Logro de
Resultados
previstos
La identificación
de desviaciones
La incorporación
de medidas
correctivas para
asegurarlos

4. FASES DE UN PROYECTO TIC
Fase 1
• Inicio y
definición de
un proyecto
TIC
Fase 2
• Desarrollo
del
Proyecto
Fase 3
• Implantación,
puesta en
marcha y
utilización por
los usuarios
Fase 4
• Operación y
Mantenimiento
de la solución
desarrollada

5. Todo proyecto TIC debe tener un patrocinador y son diversos
Los motivos que pueden llevar a un individuo dentro de
la organización a plantear la posibilidad de patrocinarlo.
Usuario quien
detecte la
necesidad de un
nuevo sistema.
Inicio de un
proyecto como
consecuencia de
un problema en el
sistema actual que
puede ser grave en
un futuro
En la mayoría de
los casos suele ser
el director o un
responsable fuera
del dpto. TIC quien
detecta el
problema y analiza
si se puede llevar o
no un proyecto

6. Es al inicio del proyecto cuando…
Se especifica el alcance de la
necesidad de:
Modificar o mejorar
un sistema actual
Desarrollar uno
nuevo
Adquirir una solución
estándar de
mercado(ERP, SCM, etc)

7. Para todo proyecto TIC
¿ Cuales son las pautas bajo las cuales deberá funcionar el nuevo sistema?
¿ Qué tipos de información requerirá?
Resultados esperados
¿ Quienes se encargarán de la toma para llevar a cabo el proyecto?
Adicionalmente…
Identificar y evaluar los posibles cambios organizativos y de
procesos de gestión internos y asociados al nuevo proyecto.
Planificar su adaptación de forma consistente con la ejecución y
desarrollo del mismo

8. Fase de Desarrollo de Proyectos
Desarrollo del
Proyecto
Creación
Adquisición
Hardware y
Software
Configuración

9. Enfoques de Desarrollo
Ciclo de vida
Prototipaje
Desarrollo Conjunto
Paquetes de Aplicación

10. Ciclo de Vida
Análisis Diseño Programación Instalación

11. Análisis del Sistema
Análisis
Viabilidad Económica
Costos de:
Personal, capital, mantenimiento, Soporte, etc.
Criterios Técnicos
Viabilidad Organizacional

12. Diseño del Sistema
Fiabilidad
Rendimiento
Escalabilidad
Seguridad
Marca

13. Diseño del Sistema
• Fase Conjunta
Diagnóstico
• Diseñador
• Usuario
Conceptualización
• Técnios
Requerimientos
• Evaluación de alternativas
Selección

14. Criterios de Selección

15. Instalación del Sistema
Conversión en paralelo
Conversión Piloto
Conversión Modular (Fases)

16. Consideraciones sobre el desarrollo de proyectos de Tics
mediante el ciclo de vida tradicional
Numerosos casos de fallos que no satisfacen las necesidades de usuarios
finales, o se completan con desfases presupuestarios exorbitantes
Se pierde el sentido de aplicar una metodología, que después de
recolectar la información sobre las necesidades, se encierra en la
trastienda, y reaparece luego de un largo tiempo con un producto que se
supone satisface las necesidades especificadas de antemano
Es muy difícil para el usuario final saber exactamente que es lo que va a
necesitar del sistema, una vez este en explotación. Se tiende a sobre-
especificar sus requerimientos, “por si acaso”, ya que saben de la
dificultad de agregarlas una vez que ha pasado a los programadores. Esto
no es suficiente en muchos casos, ya que al tener el sistema funcionando
y empieza a ser explotado, los usuarios finales tienen mejores ideas de
cómo debería ser el sistema

17. Consideraciones sobre el desarrollo de proyectos de Tics
mediante el ciclo de vida tradicional
Desarrollo mediante prototipaje
Parte de la creación de un primer sistema simplificado (prototipo) al cual
se le determinaran en mas detalle, lo requisitos para la construcción del
sistema real.
Construcción
Prototipo inicial
Evaluar el
prototipo
decidir
abandonar
Prototipaje
exitoso
revisar
prototipo
Pasar al ciclo de
vida tradicional
Completar el
sistema a partir
del prototipo

18. Consideraciones sobre el desarrollo de proyectos de Tics
mediante el ciclo de vida tradicional
Desarrollo conjunto
Refieree a la fase de recogida de características deseadas del sistema o
producto de TIC. Pretende aligerar la recopilación de requisitos de
usuarios finales a la hora de iniciar el análisis del mismo.
Reuniones individuales e independientes con usuarios lideres para
recogida de requisitos
Los analistas compilan toda la información y presentan una propuesta a
los usuarios, quienes normalmente no están de acuerdo, y debe iniciarse
un proceso iterativo para llegar a un acuerdo sobre las funcionalidades a
implantar.

19. Consideraciones sobre el desarrollo de proyectos de Tics
mediante el ciclo de vida tradicional
Desarrollo conjunto
La metodología requiere de un moderador o principal tomador de
decisiones que controle la reunión.
A pesar de ser una solución bastante útil y acertada, la realidad no
permite llevarla a cabo en muchas organizaciones, debido a la dificultad
de reunir a todos los usuarios que deben participar en el análisis y diseño
de un sistema de información simultáneamente en el mismo lugar.

20. Consideraciones sobre el desarrollo de proyectos de Tics
mediante el ciclo de vida tradicional
Desarrollo mediante la implantación de paquetes
La selección de paquetes de mercado, su implantación, con las consideraciones y requisitos:
Alineación de procesos del negocio y las funcionalidades del ERP
Participación de los directivos
Escoger el equipo apropiado
Selección y gestión de los consultores
Disponer de una metodología clara de implantación
Involucración y formación de usuarios desde el inicio
Mejora continua y mantenimiento de la funcionalidad

21. Consideraciones sobre el desarrollo de proyectos de Tics
mediante el ciclo de vida tradicional
La implantación no obvia la fase de recogida de necesidades, aunque en
cierta medida viene mediatizada por la existencia de una determinada
solución en partes de la empresa
Desarrollo mediante la implantación de paquetes

22. FASE 3
IMPLANTACIÓN PUESTA EN MARCHA Y UTILIZACIÒN POR LOS USUARIOS
Proceso de Interacción con los usuarios finales para una implantación
exitosa
Detección de oportunidades de mejora en los procesos de
negocio a formatizar
Definición de requisitos redquisitos
Documentos y rediseño de los procesos de negocios afectados
Diseño de elementos externos al propio sistema

23. Validación de la ergonomía, la funcionalidad y la usabilidad
Validación de maquetas y prototipos
Redacción de normativas y manuales de usuario
Elaboración, validación del material para la formación e
información
Formación a formadores
Comunicación y venta del nuevo sistema, mediante reuniones
presenciales y con instrumentos de apoyo para la capacitaciòn

24. Elaboración y validación del material de divulgación
Validación del plan de puesta en marcha
Sugerencias post-implantación
Estudios de satisfacción

25. Fase 4. Operación y mantenimiento de la solución desarrolla.
La fase 4, representa la puesta en marcha del nuevo sistema; se debe
garantizar la adecuación del mismo a las necesidades del negocio y
del mercado (mantenimiento evolutivo) y además la disponibilidad y
la calidad del sistema resolviendo los problemas detectados durante su
ejecución (mantenimiento Correctivo), pero lo que realmente
garantizará la eficiencia del sistema es el diseño de políticas de control
de calidad, específicas y rigurosas, desde el inicio del proyecto

26. El concepto de riesgo de un proyecto.
Todo proyecto se basa en proyecciones de escenarios. Al no tener
certeza sobre los flujos futuros que ocasionará cada inversión, se
estará en una situación de riesgo o incertidumbre.
El riesgo de fracaso del proyecto debe minimizarse desde el momento
de la planificación, es decir detectar e intervenir el problema con
anticipación antes de que éste sea irresoluble. Sin embargo la
mayoría de los estudios de variabilidad que se realizan antes de
comenzar un proyecto raramente contienen documentación acerca de
los posibles riesgos derivados, por ejemplo, de los retrasos en las
entregas, errores técnicos o el fracaso en general

27. Ignorar los riesgos en un proyecto trae como
consecuencia:
 Problemas con los beneficios anticipados debido a dificultades
durante la implantación.
 Costes de implantación más elevados de lo esperado.
Plazos de entrega más largos de los previsto.
Sistemas con rendimientos menor a lo esperado.
Incompatibilidad del sistema con el software y hardware previstos.
Dimensiones que influyen en el riesgo:
1. Tamaño del proyecto
2. Experiencia con la tecnología.
3. Estructura de los procesos a informatizar

28. Dimensiones que influyen en el riesgo.
Tamaño del Proyecto:
Cuanto mayor sea la dimensión del proyecto en términos monetarios, número de
colaboradores, tiempo necesario y número de departamentos que afecta, mayor será el
riesgo.
Experiencia con la tecnología:
Se deben evaluar dos colectivos el técnicos y los usuarios. El riesgo de problemas
técnicos aumenta en cuanto sea menor el conocimiento del Software y hardware de los
sistemas operativos, de las bases de datos y del lenguaje utilizado por parte del equipo.
Estructura de los procesos a informatizar
Son menores los riesgos en aquellos proyectos en los que las tareas están estructuradas
desde el inicio y no permiten excesivos cambios ,que aquellos que si permiten
modificaciones durante la realización

29. Elevada estructuraBaja estructura
Riesgo medio (muy
susceptiblea una mala
dirección del proyecto)
Riesgo bajo
(muy susceptiblea una
mala dirección del
proyecto)
Reiesgo muy elevado
Riesgo elevado
Baja tecnología
Riesgo bajo
Riesgo muy bajo
Riesgo medio
Riesgo medio bajo
Alta tecnología
Proyecto grande
Proyecto pequeño
Proyecto grande
Proyecto pequeño
Tabla de riesgos

30. Nivel de la Tarea
Requerimientos
de Conocimientos
de Tecnología
Habilidades de
Liderazgo
Habilidades de
Gestión

31. Características del Responsable
LIDER
Sist.
Genéricos de
G.P.
Herramientas
Disponibles
Control de
Tiempo
Factores de
Riesgo
Recursos
Utilizados
Caract.
Diferencial de
los Proy.

32. Responsabilidades del Lider
Control de Gastos
Control de Tiempo
Control de
Personal

34. No Tratamos el Problema Correcto
Todo proyecto entraña la necesidad de
resolver un problema
La misión no está articulada de forma realista
No se comprende claramente la dimensión de la crisis
porque cada grupo tiene su propia visión de la misma

35. Diseñamos lo que no era
Suele ocurrir que los equipos de trabajo se apresuran para luego
descubrir que ciertos detalles se han hecho de forma errónea o se
han omitido por completo
El proyecto no estaba delineado correctamente en todas
sus dimensiones
No se ha dejado participar al cliente como es debido
Se ha perdido algún eslabón al transformar los
requisitos en diseño

36. Utilizamos la Tecnología Equivocada
La elección de un tipo de tecnología u otra depende
del entorno en que la empresa se desenvuelve.
La tecnología no cubra las necesidades funcionales de la
empresa
Elegir la tecnología adecuada y que el personal que
debe manejarla carezca de las aptitudes necesarias
La tecnología no pueda hacer frente al creciente
volumen de negocios

37. El Equipo no Congeniaba
Un equipo de trabajo bien estructurado es aquel en el que cada
miembro comprende su papel en la ejecución del proyecto y lo
desempeña de forma adecuada.
La organización del proyecto no es clara y los papeles no
están bien trazados
Cuando se producen diatribas entre sus miembros y se
culpan en público de los errores

38. No involucramos a la Gente Adecuada
Alguna persona que, al no ser incluida en el proyecto, ha provocado
la ruina del mismo o, al menos, ha conseguido ralentizarlo.
No se ha involucrado a la gente adecuada cuando no
existe una definición clara de quién es el cliente.
Cuando no se ha identificado a aquellos que pueden
catapultar el proyecto hacia el éxito o el fracaso

39. No comunicamos adecuadamente
Elaborar y ejecutar un plan de comunicaciones sólido va a resultar
determinante para que el proyecto alcance buenos resultados
El no definir con claridad al público objetivo o no circunscribirse a
él adecuadamente.
Los indicios de que algo no marcha bien son las preguntas que el
público objetivo hace sobre cuestiones que ya han sido explicadas.

40. Otros Errores Importantes
Intentamos hacer demasiado
No teníamos un Plan B
No prestamos atención a los riesgos del proyecto
El proyecto costó mucho más de lo que se esperaba