Transcript Alternativas Organizacionales para la Administración

Administración de la Producción de
Sistemas Computacionales
Si00-875
Módulo 2:
Evaluación Preliminar del
Proyecto
Ing. Ignacio Cabral Perdomo, M.C.
ITESM - CCV
¿Cómo organizamos el proyecto?
No hay un patrón general que responda a:
• ¿Cómo se asignarán las responsabilidades del
administrador del proyecto y los otros miembros
del equipo?
• ¿A quién reportará el administrador del
proyecto? ¿A qué nivel y en qué parte de la
organización?
¿Habrá una oficina especial para el
proyecto o permanecerán los
contribuyentes al mismo en sus propios
departamentos?
•
• ¿Quién es responsible del desarrollo y
operación de los sistemas de control y
planeación para multiproyectos?
En pocas palabras:
¿Cómo se organizará administrativamente
el proyecto?
Alternativas Organizacionales para
la Administración de Proyectos
Se recomiendan tres principalmente:
•
Puramente funcional.
•
Matriz función-proyecto.
•
Proyecto puro.
Se habla del “continuo organizacional”
Alternativas Organizacionales para
la Administración de Proyectos
Alternativas Organizacionales para
la Administración de Proyectos
Alternativas Organizacionales para
la Administración de Proyectos
Alternativas Organizacionales para
la Administración de Proyectos
Alternativas Organizacionales para
la Administración de Proyectos
Alternativas Organizacionales para
la Administración de Proyectos
Alternativas Organizacionales para
la Administración de Proyectos
Principio básico del lugar de reporte
“La función de administración del
proyecto deberá reportar al administrador o
ejecutivo de línea que resuelva realmente
todos los conflictos dentro y entre los
proyectos a ser administrados”.
Otros factores tales como tamaño,
alcance, y naturaleza del proyecto afectan
el sitio a donde se reportará.
Responsabilidades del administrador
general del proyecto:
• Proveer dirección diaria a los administradores
o especialistas asignados a la oficina del
proyecto.
• Resolver conflictos de prioridades, recursos y
otros que se presenten.
• Seleccionar al personal del proyecto basado
en sus habilidades.
Responsabilidades del administrador
general del proyecto:
• Desarrollar e implementar prácticas de
administración de proyectos y sistemas de
información para el control del proyecto.
• Informar a la alta dirección del progreso y
problemas en todos los proyectos.
El equipo staff para el proyecto:
Tres opciones básicas:
• Asignar personas directamente a la oficina del
proyecto, bajo el control del administrador del mismo.
• Asignar las tareas requeridas para el proyecto a
departamentos funcionales específicos o staffs
especializados.
• Contratar tareas y trabajos para el proyecto fuera de
la organización.
Pensemos: ¿qué ventajas tiene cada una de
ellas? ¿cuándo usar una u otra?
Servicios de soporte a la ADP:
• Responsable del proyecto.
• Contabilidad del proyecto.
• Servicios administrativos especializados para la
ADP.
• Planeación.
• Estimación.
• Identificación de interfaces.
• Presupuestos.
• Control del alcance de trabajos.
• Autorización y control de trabajos.
Servicios de soporte a la ADP:
• Control y programación de tiempos.
• Control de costos.
• Monitoreo y evaluación del proyecto.
• Administración general.
• Servicios especializados de soporte en
procesamiento de datos (por ejemplo Lotus Notes
o herramientas de groupware).
Un proyecto grande es en realidad
una tarea muy compleja
Los roles clave en la ADP:
•
Nivel ejecutivo:
• El administrador general
• El patrocinador del proyecto
• Nivel multiproyectos:
• El administrador de la administración del
proyecto.
• Nivel proyecto:
• El administrador del proyecto
• Nivel de departamento funcional o contribuyente
al proyecto:
• El líder funcional del proyecto.
El administrador general:
Su papel en la DP está enfocado en el proceso de
administración de proyectos generales de toda la
organización, y cómo están integrados éstos con
otros aspectos de la organización.
• Asegurar proyectos correctos
• Proveer recursos adecuados
• Asegurar que se usen prácticas adecuadas de
ADP
• Monitorear el desempeño general de los
proyectos.
El administrador de la ADP:
Planea, organiza, evalúa, dirije, controla y lleva el
proyecto de inicio a fin.
Responsabilidades:
• Producir el producto final o resultado dentro de las
especificaciones técnicas, de costos y de tiempos con los
recursos disponibles en la organización.
• Cumplir los objetivos de ganancia del proyecto si está por
contrato.
• Integrar los esfuerzos de todos los miembros
contribuyentes al proyecto, proveer liderazgo al equipo.
• Alertar a la alta administración, en cualquier momento, si
las requerimientos técnicos, de costo, o de tiempo no se
cumplirán.
El administrador de la ADP:
• Tomar o forzar las decisiones requeridas
para asegurar que los objetivos del
proyecto se cumplirán.
• Recomendar la finalización del proyecto
o una solución alternativa si los objetivos
del proyecto no pueden ser alcanzados.
El administrador de la ADP:
• Servir como el primer punto de contacto
entre el proyecto con el cliente, la alta
administración y los administradores
funcionales.
• Negociar “contratos” (órdenes de trabajo)
con los diversos departamentos
funcionales para desempeñar labores de
acuerdo a las especificaciones y dentro de
los tiempos y costos señalados.
Responsabilidades y autoridad
Las responsabilidades y autoridad asignadas a
cada persona dependen de:
• El tamaño y la naturaleza de la
organización.
• El tamaño y naturaleza del proyecto y de su
actual fase en el ciclo de vida.
• El número de proyectos ejecutándose.
• Las capacidades de los administradores
involucrados.
• La madurez de la función de ADP dentro de
la organización.
Algunas características
Características personales de administradores de
ADP efectivos:
• Flexibilidad y adaptabilidad.
• Preferencia por la iniciativa y el liderazgo.
• Agresividad, confiable, persuasivo y con
influencia
verbal.
• Ambicioso, activo.
• Efectivo en comunicación e integrador.
• Amplio campo de intereses personales.
Algunas características
• Entusiasmo, imaginación y espontaneidad.
• Capaz de balancear soluciones técnicas con
tiempo, costo y factores humanos.
• Bien organizado y disciplinado.
• Un generalista más que un especialista.
• Capaz de dedicar la mayor parte de su tiempo a
la planeación y control.
• Capaz de identificar problemas.
• Hacer decisiones correctamente.
• Capaz de mantener un balance justo en el uso
de su tiempo.
Habilidades en ADP
(Métodos y herramientas)
Integrador
Habilidades de
equipo y personas
El administrador
del Proyecto
Habilidades
Habilidades técnicas
(Disciplina de su especialidad)
Habilidades administrativas
básicas y de negocios
Conocimiento del papel
del patrocinador del proyecto
Conocimiento Ambiente
del proyecto
El papel del Administrador de
proyectos
A one-track mind cannot effectively
manage a two-track railroad
Russel Ackoff
•
Lidiar con la resistencia.
•
Necesidad de flexibilidad.
•
Es una labor difícil y que requiere experiencia
y muchas características especiales.
El papel del Administrador de
proyectos
Algunas ideas:
• Algunas veces la negativa a cooperar es
causada por quienes se sienten amenazados.
• “Si usted hace lo que siempre ha hecho,
obtendrá lo que siempre ha obtenido”.
• “Si usted trata algo repetidamente y no tiene
éxito, entonces ¡Trate algo diferente!”
El papel del Administrador de
proyectos
Algunas ideas:
In any system of men or machines, the
element in the system with the greatest
flexibility in its behavior will control
the system.
Ross Ashby
Evaluación preliminar del proyecto
Cinco preguntas básicas
¿Involucra el trabajo la
integración de muchos
componentes en un
todo operacional
funcionando?
1
Cinco preguntas básicas
¿ Es el trabajo muy
grande o complejo
técnicamente ?
2
Cinco preguntas básicas
¿ Cree firmemente la
alta gerencia que un
individuo solo deberá
estar disponible para
servir como un punto
focal para información
y responsabilidad ?
3
Cinco preguntas básicas
4
¿ Está siendo
desarrollado el
proyecto en un
ambiente de
requerimientos
cambiantes ?
Cinco preguntas básicas
5
¿ Requiere la tarea que
un grupo diverso de
profesionales sean
reunidos para trabajar
por un objetivo común ?
Conceptos básicos
Todo proyecto inicia con un problema.
Al terminarse el proyecto podemos cuestionar:
¿ Cumple el producto final con solucionar el
problema del usuario ?
¿ Está satisfecho el usuario con el proceso de
desarrollo ?
¿ Está la alta administración satisfecha con el
producto así como con el proceso ?
¿ Está satisfecho el equipo del proyecto ?
¿Por qué tienen éxito los proyectos
al usar ADP?
Básicamente:
Un inicio limpio de todas
las actividades.
Planeación y control de
actividades y del proceso.
Un enfoque profesional y de
calidad para el desarrollo.
Razones para la ADP de Software
Razón 1.
El creciente tamaño y complejidad de los proyectos
de desarrollo de software está haciendo que la
administración casual de proyectos sea imposible.
Razón 2.
El desempeño consistente y predecible no es posible
usando la administración casual de proyectos.
Razones para la ADP de Software
Razón 3.
Al usar administración casual, no es posible el
delegar efectivamente las tareas de administración
del proyecto mientras se retiene el control sobre
todo el proyecto.
Razón 4.
La curva de aprendizaje para el nuevo administrador
de proyecto es inaceptablemente larga cuando se
usa la administración casual.
Ciclos de vida del software
Identificación de
requerimientos
Ciclo de vida del desarrollo de SW
Diseño
Código
Mantenimiento
Prueba y
liberación
Análisis
post
finalización
Análisis y
Evaluación
Mercadotecnia
Ciclo de vida de la administración del proyecto
Según Roetzheim, 1988
Structured Computer Project Management
Fase de Análisis y Evaluación del Proyecto
Análisis de
requerimientos
Diseño
preliminar
Entrevistas y
Documentos del
Cliente
Estudio de
Factibilidad
del
Proyecto
Análisis de
alternativas
Evaluación del
Proyecto
Estimación
Evaluación
preliminar
del
proyecto
Fase de Mercadotecnia del
Producto
Se obtiene como resultado la propuesta del
proyecto.
• Definir exactamente qué se intenta hacer por el
cliente.
• Convencer al cliente que la propuesta cumplirá
con sus necesidades.
• Decir al cliente cómo se intenta producir el
software.
• No dejar duda en la mente del cliente de que se és
capaz de producir el software.
• Incluir toda la información necesaria para permitir
que el propio documento “venda” el producto.
Fase de Diseño Preliminar
Espec. De
Diseño del
sistema
Espec. De
funcional del
programa
Actividades de
la etapa de
Diseño
Plan de
Proyecto
Espec. De
Diseño del
programa
Nuestra brújula a lo largo del proyecto:
El diagrama de fases del proyecto (Rakos, 1993)
Definición
Análisis
Diseño
Programación
Pruebas
Aceptación
Operación
¿ Cómo construímos una casa ?
La primera
cuestión es
que existen de
varios
tamaños.
Puede construirla una
sola persona
Requiere:
Mdelado mínimo
Proceso simple
Herramientas simples
Construída más eficientemente y
a tiempo por un equipo completo.
Requiere:
Modelado
Proceso bien definido
Herramientas poderosas
Fuente: Rational Corporation
¿Qué pasa con un rascacielos?
Fuente: Rational Corporation
Arquitectura Temprana
Progreso:
Limitado
conocimiento de
la teoría.
Fuente: Rational Corporation
Arquitectura Moderna
Progreso
Avances en materiales
Avances en análisis
Avances en ADP
Scalas:
5 veces la cúpula del
panteón de Roma.
3 veces la altura de
la pirámide de Keops.
Fuente: Rational Corporation
Modelando una Casa
Requerimos de
un proyecto.
También de
una maqueta
Fuente: Rational Corporation
Ejercicio:
Discutir en grupo cómo se comparan las fases
del proyecto de software con la construcción de una
casa:
Definición
Análisis
Diseño
Programación
Pruebas del sistema
Aceptación
Operación
Fase de Definición del Proyecto
El objetivo primordial de esta fase es el obtener el
suficiente entendimiento del problema del usuario con el
fin de estimar costos y tiempos.
3 Actividades principales:
• Obtención de los requerimientos del usuario.
• Decisión de hacer o nó el proyecto.
• Escritura de la propuesta del proyecto.
Actividades de la Fase de Definición
Documento de requerimientos (DR)
Firma del DR por el usuario y el equipo del proyecto
Plan Preliminar del Proyecto (PPP)
Propuesta preliminar resultado del análisis
Propuesta de Desarrollo
El Documento de Requerimientos (DR)
• Establece el problema del usuario y las soluciones
generales requeridas.
• Está escrito en el lenguaje de trabajo del usuario, no
en términos computacionales.
• Se utiliza en ocasiones como una “requisición para
propuesta” (contratos externos a la compañía).
• Se dedicará mucho tiempo con el usuario, quien no
es una persona técnica.
La Entrevista con el Usuario
• Información correcta = buen DR
• Problema real: encontrar al verdadero
usuario final del producto.
• Primer paso fundamental: aprender del
negocio.
• Planear la entrevista.
La Entrevista con el Usuario
•
Iniciar con las salidas.
• ¿ Cómo fluye la información entre los departamentos
e individuos ?
•
Determinar: frecuencia, tiempos y exactitud.
• Continuar con las entradas (¿qué información se
requiere para producir las salidas?)
•
Las cinco Ws: Who? What? Where? When? Why?
•
El “cómo” pasa a la etapa de diseño.
Contenido del DR
1. Introducción.
• Identificar la compañía y a los responsables de la
autorización del proyecto, así como al usuario.
• Problemas a ser resueltos, historia del problema,
ejemplos de la situación problemática, motivaciones
para darle solución.
Esta sección sensibiliza al equipo con el usuario y su
problema.
Contenido del DR
2. Objetivos del Proyecto.
Un estatuto simple sobre el por qué estamos
proponiendo el desarrollo. Se pueden mencionar
restricciones de tiempo y dinero.
3. Principales Funciones.
Estatutos simples (sin detalles) acerca de cómo
funcionará el sistema, basados en los objetivos del
proyecto.
Contenido del DR
4. Salidas Generales.
Descripción simple de la información requerida del
sistema.
Nota: detallar toda la información (nó pantallas o
reportes) requerida.
5. Entradas generales de información.
Revisar las salidas y determinar los datos de entrada
necesarios para producirla.
Nota: Un usuario sin experiencia no podrá determinar
este punto. Puede ser llenado después por el analista.
Contenido del DR
6. Desempeño.
Número de transacciones a procesar, cantidad de
datos a almacenar, frecuencia de reportes. Describir
todo en términos de promedios y máximos.
7. Crecimiento.
Estimar el crecimiento del negocio y los años que el
sistema funcionará..
Contenido del DR
8. Operación y ambiente.
Lugar físico donde residirá el sistema, dónde estarán
las terminales, quién lo usará. Medidas de seguridad
para ambientes hostiles.
9. Compatibilidad, interfaces.
Aclarar si se requiere comunicación con otros
equipos, protocolos posibles, acceso distribuído, etc.,
además de otros productos de software con los que
interaccionará el sistema.
Contenido del DR
10. Disponibilidad.
Indicar el MTBF (Mean Time Between Failures) y el
MTR (Mean Time to Repair).
11. Interface humana.
Experiencia computacional requerida por el usuario,
indicar cómo manejarán los nuevos usuarios al sistema
(conducido por menús, ayuda en linea, etc.)
Contenido del DR
12. Impacto organizacional.
Qué departamentos serán afectados y cómo
cambiará su forma de trabajo. Cómo interaccionará el
sistema con sistemas manuales (existentes o nuevos).
13. Mantenimiento y soporte.
Tiempo de garantía y tiempo de respuesta cuando se
notifiquen fallas.
Contenido del DR
14. Documentación y Entrenamiento.
Qué documentos y/o cursos se requerirán.
Manuales para usuario, operadores y mantenimiento
del sistema. Cursos de entrenamiento para usuarios.
15. Ventajas del sistema (sólo para RFP).
Solicitar datos a los vendedores sobre su situación
competitiva, posición en el mercado, por qué sienten
que deben ser seleccionados.
Contenido del DR
16. Términos y condiciones (sólo para RFP).
Establecer las bases para la selección, cuándo y
cómo se notificará el ganador del concurso o de la
licitación.
Se puede anexar cualquier otro punto
que reforce este documento
Responsabilidades del usuario
El usuario tiene que cumplir dos responsabilidades
fundamentales:
• Estar disponible (o tener disponibilidad de tiempo)
• Tener cierta autoridad para hacer decisiones con
respecto al sistema propuesto.
Cuidado:
Se deben seleccionar bien los usuarios, nuevamente:
¿Quién es realmente el usuario del sistema?
Decisión:
Go/No-Go
Dos preguntas básicas:
•
¿Es técnicamente factible el proyecto?
•
¿Lo puedo (o podemos) hacer?
Cuando se opte por la decisión NO, la mejor
forma de decirlo es con razones financieras,
NUNCA decir: ¡No puedo!
Existen ocasiones en que se debe llevar a
cabo el proyecto forzosamente.
¿Por qué es importante hacer la
evaluación preliminar?
• Se asegura que el proyecto sea o no
aceptado y sobre todo que sea entregado a
tiempo y dentro del presupuesto.
• Va a influir en la decisión go/no go
Puntos críticos de decisión
¿Qué son dichos puntos?
• Son puntos identificables en la vida
del proyecto en los cuales el
proyecto es evaluado y se hace una
decisión sobre si continuar al
siguiente paso del desarrollo o
dejarlo a un lado.
Puntos críticos de decisión
Hay tres principales
Factibilidad
Diseño
Desarrollo
Puntos críticos de decisión
Operación
Puntos críticos de decisión
Beneficios
• Las revisiones de los estimados de costo y
desempeño serán más precisos que los
estimados previos.
• Se pueden solicitar fondos extras sustanciales
con el fin de proceder al siguiente paso.
• El proyecto está en un punto lógico de paro.
Puntos críticos de decisión
Preguntas básicas
• ¿Es técnicamente factible el proyecto?
• ¿Es económicamente factible?
• ¿Podrá terminarse en el tiempo asignado?
• ¿Cuáles son los riesgos al aceptar el proyecto?
• ¿Cuáles son los beneficios?
• Los beneficios, ¿superan a los riesgos?
Componentes principales
de un proyecto de informática
1. De trabajo intensivo
Involucran el gasto significativo de
mano de obra humana en la organización
para desarrollar un producto nuevo y
personalizado.
Ejemplos: programas de software,
entrenamiento, instalación, mantenimiento y
diseño de tarjetas electrónicas.
Componentes principales
de un proyecto de informática
2. Productos estándar
Involucran la venta de productos de
“estantería”
Ejemplos: componentes computacionales,
software empacado, sistemas operativos y
aplicaciones estándares ya listas.
Calculando lo básico
Determinar
las cuentas
a incluir
Descomponer
el proyecto
Según:
Roetzheim, 1988
Resumir los
cálculos de
cuentas
Características
del proyecto
Estimar el trabajo
intensivo
Estimar la
renta
de productos
Estimar la
compra
de productos
Completando el análisis
financiero del proyecto
Herramientas
• Retorno sobre la inversión (ROI).
• Vuelta de activos (Asset Turnover).
• Índice de Roetzheim.
• Índice de Disman.
• Índice de Olsen.
Evaluación de riesgos
Tema muy importante.
Le dedicaremos otro juego de
filminas a este tema.
Impacto en la estrategia y
objetivos tácticos corporativos
• El aspecto cuantitativo no es el único factor.
• Puede haber otros usos y explotaciones del
hardware y del software.
• El proyecto puede servir como un medio de
entrenamiento al personal.
• Oportunidad de ganar reputación en un área
de “expertise”.
Modelo de contribución de valor
• Es un modelo que nos permite
combinar toda la información
obtenida de los análisis anteriores y
de ahí partir a la decisión go/no go
para el proyecto.
Modelo de contribución de valor
• Pasos a seguir:
Enlista y pondera
los criterios de
alto nivel
Enlista y pondera
los criterios
expandidos
Define las
guías para
valuar
Modelo de contribución de valor
Criterios de alto nivel:
Modelo de
Contribución de
la empresa
Factores
Financieros 0.5
Factores
de riesgo 0.3
Nota: todos suman 1
1
Factores
estratégicos 0.2
Modelo de contribución de valor
Criterios expandidos:
Modelo de
Contribución de
la empresa
Factores
Financieros 0.5
0.5
ROI
0.5
Índice de
Roetzheim
1
Factores
de riesgo 0.3
0.5
Otros usos
del SW
Factores
estratégicos 0.2
0.2
Entrenam.
potencial
0.3
Desarrollar
experiencia
Modelo de contribución de valor
Definiendo la valuación:
Modelo de
Contribución de
la empresa
85
ROI
1
50
Factores
Financieros 0.5
90 0.5
Total del
Proyecto:
69.3
59
Factores
de riesgo 0.3
Factores
estratégicos 0.2
80 0.5
60 0.5
10 0.2
90 0.3
Índice de
Roetzheim
Otros usos
del SW
Entrenam.
potencial
Desarrollar
experiencia