28

Por Que Fallan Los Proyectos de Sw

Embed Size (px)

DESCRIPTION

manual

Citation preview

  • Ofrecemos soluciones que encajan con nuestro inters "personal" o verdadero conocimiento.

    No con el objetivo real del proyecto.

  • El objetivo de cualquier proyecto, es el xito. Del proyecto mismoDel clienteEl Nuestro

  • La preocupacin debe ser llegar al xito por el camino ms corto posible.

    Esto no significa que el fin justifique los medios.

    Ms bien, al contrario:"al fin justifiqu los medios"

  • Nos encontramos con varios elementos al transitar por estos "medios". No confundir los medios tecnolgicos con los medios estratgicos y metodolgicos.El conocimiento tecnolgico est ah. Documentado, en cursos, manuales, memoria, etc.

  • Hay que ser como dios (o Dios): no hay que dar al cliente lo que quiere, sino lo que necesita. Distinguir claramente entre lo que el cliente cree necesitar y lo que realmente necesita para lograr el xito.Actualmente todos "somos" expertos informticos. Todos "creemos" saber ms que los dems. El cliente es como un nio en Navidad. Muchos no saben lo que necesitan y slo piden lo que quieren o creen necesitar.

  • Las primeras fallas se dan durante la fase de integracin del proyecto.

    Definicin

    Si no definimos claramente qu vamos a obtener con el proyecto, cmo vamos a lograrlo.

  • Alcance

    Si no ponemos los lmites al proyecto, cmo sabremos que hemos terminado.

  • Administracin

    Si no administramos o controlamos el proyecto, como vamos a saber en donde estamos.

    Es como ir de viaje en un camino sin sealizacin, sin un mapa, sin indicador de kilometraje o nivel de gasolina, velocmetro, etc.

  • Falla en el presupuesto del proyecto.Una mala planeacin nos lleva a fallas en tiempo y en dinero.No se contempl todo el dinero que se requera.Proyecto: Servidor.Y la conectividad?Y la proteccin elctrica?Y el software?Y la administracin del servidor?

  • El presupuesto no solo es dinero. Tambin son tiempos. Los tiempos muertos entre implementaciones cuestan.Los tiempos de pruebas cuestan.A pesar de que muchos "patrones" no paguen horas extras a sus empleados por capacitacin, no significa que ese tiempo no tenga un costo. Los costos de capacitacin de parte de los usuarios finales al proyecto.

  • El descontento es un costo difcil de medir, pero su impacto puede ser fatal. Las pruebas mal planeadas, que generan re-trabajo de parte del personal.No siempre el costo lo absorbe el cliente.Cuntas veces se prolonga la fase de cierre del proyecto, y seguimos casi como abonados con el cliente.Eventos comerciales

  • Considerar:HolgurasDe dineroTipo de cambioCambio de precioDe tiempoEnfermedadesDas festivosEventos comerciales

  • Fallas de calidadSe conecta!!!S, pero a qu velocidad y con qu tiempo de respuesta. VPN con inicio de operaciones de 1hr.

    Permite la captura de la forma "X"!!!S, pero con cunta redundancia de datos a capturar.Cuantos movimientos de mouse(hay muchos estudios acerca de la fase de diseo)Centrarnos en la necesidad del usuario. (Ojo, no en lo que quiere el usuario)

  • Falta de compromiso de los altos niveles de la empresa.Cuntas veces nos embarcamos en proyectos que la direccin no conoce, no le interesa, o que si lo conociera, posiblemente no autorizara desde un principio.Falta de un estudio a fondo de la empresa. Sus necesidades reales y actuales. Su situacin financiera, laboral. El status actual de nuestro contacto dentro de la empresa.Capacidad y pertinencia en la toma de decisiones.

  • Falta de anlisis del procesoPoca visin. OXXOQuin no critic el "feo" sistema del OXXO. Cuntos no hubieran sustituido su interfaz plana por un ambiente grfico. Cul es el objetivo del punto de venta de OXXO?ASPEL DOS vs ASPEL Windows.Para qu usar el mouse cuando no es necesario.

  • Falta de control o administracin durante el desarrollo del proyectoSe estableci el proyecto, OKSe defini su alcance, OKSe inici el proyecto, OKHay cambios inevitables durante el proceso del proyectoSe controlan? Se documentan?Se acta en consecuencia?Se registran y comunican las implicaciones?

  • Falta de control o administracin durante el desarrollo del proyectoUn simple checklist muchas veces es suficiente.La complejidad del proyecto determina la complejidad de su administracin

  • Falta de control o administracin durante el desarrollo del proyectoCharvat (2003). Diferencias en el xito entre proyectos desarrollados utilizando o no metodologas.

  • Suposiciones del proyectoParte de los riesgos del proyectoSe debe ser autocrtico para detectarlasSupongo que la aplicacin funciona correctamente en VPNLa probaste? (cunto nos cuesta hacer una prueba en VPN vs los tiempos muertos durante la implementacin?)Supongo que el proveedor de internet es confiableHay estudios que lo certifiquen?Hay opciones?Puedo hacer pruebas antes de empezar?

  • Suposiciones del proyectoCapacidad (tecnolgica, administrativa) del equipo del proyecto.Tiene (tenemos) la capacidad y los conocimientos para realizar el proyecto al 100%?

    Supongo que me acuerdo de todoEl ms riesgoso de todos

  • Fallas de comunicacinEstablecer canales oficiales de comunicacin durante el desarrollo del proyectoCorreo con ttulo pertinente.Ej.: Proyecto SITE: Problema de infraestructuraLo que est escrito sirve para cotejar en caso de divergenciaConfirmacin de lecturaReglas de mensajesSistemas de comunicacin organizacionalComunicacin interna al equipo del proyecto

  • Fallas en documentacin y registroTodas las eventualidades, todos los cambios, todos la informacin utilizada durante el proyecto.Servir como informacin para futuros proyectos similares. A pesar de que los proyectos nunca son los mismos, comparten algunos elementos

  • Evidencias:Por qu fallan los proyectos informticos? Por qu no son existosos los proyectos informticos?Grupo Standish: 31.1% de los proyectos se cancelan antes de terminar. 52.7% de los proyectos cuestan 189% ms que sus estimaciones originales.Costos de oportunidad

  • Evidencias: Grupo Standish:

    Factores de Falla o cancelacin%Requerimientos incompletos13. 1Deficiencia en el involucramiento del usuario12.4Deficiencia de recursos10.6Expectativas no realistas9.9Deficiencia en soporte ejecutivo (direccin)9.3Cambios en los requerimientos y especificaciones8.7Deficiencia en la planeacin8.1Ya no se necesita ms7.5Deficiencia en administracin de TI6.2Desconocimiento en tecnologa4.3Otros9.9

  • Evidencias:No todo es maloPor qu triunfan los proyectos (De acuerdo a Baker, Murphy y Fisher, de 650 proyectos estudiados en USA):1. Compromiso con el proyecto en el establecimiento de cronogramas, presupuestos y objetivo de desempeo tcnicos. (Integracin)2. Frecuente retroalimentacin de la organizacin (Comunicacin)3. Frecuente de retroalimentacin del cliente (Comunicacin)4. Compromiso del cliente, del patrocinador, en el establecimiento de cronogramas, presupuestos y objetivo de desempeo tcnicos.5. Estructura de la organizacin adecuada al equipo del proyecto

  • Evidencias:No todo es maloPor qu triunfan los proyectos (De acuerdo a Baker, Murphy y Fisher, de 650 proyectos estudiados en USA):6. Participacin del equipo del proyecto en la determinacin del cronograma y los presupuestos7. Entusiasmo del patrocinador8. Deseo del patrocinador de crear las capacidades internas9. Procedimiento de control adecuados, especialmente en relacin con los cambios10. Soporte pblico entusiasta

  • Evidencias:A partir del uso de este tipo de estructuracin de proyectosAumento en la confianza de lograr proyectos exitososAumento en la captacin de proyectos "interesantes"Aumento en el prestigio Aumento en la remuneracin30% de aumento de los ingresos en 1 ao