ACIS Project Management Por Bernardo Díaz Arias berdiaz@yahoo.com.

Presentación del tema: "ACIS Project Management Por Bernardo Díaz Arias berdiaz@yahoo.com."— Transcripción de la presentación:

1 ACIS Project Management Por Bernardo Díaz Arias

2 Project Management Problema: “El no evaluar la viabilidad de un proyecto, la planeación ligera, la ausencia de monitoreo y retroalimentación permanente minimizan el éxito administrativo de los proyectos de software así todas las demás variables se cumplan” Solución Propuesta: El PMI es una organización fundada desde 1969 cuya metodología tiene creciente aceptación mundial y resume las buenas prácticas en “Gestión de Proyectos” para cualquier industria.

3 Project Management Fortalezas:
Promueve la gestión integral (según 9 áreas de procesos). Los procesos de Planeación aplican a cualquier industria Debilidades: No detalla en como se debe ejecutar el proyecto para generar el producto o servicio. (propio de cada industria). No incluye Plantillas Requiere de experiencia para aplicar correctamente los flujos entre procesos.

4 Project Management Oportunidades:
Utilizarlo en conjunto con metodologías que definan el proceso de construcción del producto o bien del proyecto. Amenazas: Durante la planeación del proyecto tiende a darse sobrecarga de trabajo para el PM. En nuestro medio no es frecuente que el PM se pueda dedicar tiempo completo a un proyecto así sea complejo / grande.

5 Project Management Que es un Proyecto? Esfuerzo temporal y progresivo para crear un producto o servicio. Características de un Proyecto: Temporary Unique Result (product / service) Progressive Elaboration Project Management? Project Management System?

6 Project Management Posibles causas de un proyecto:
Market Demand Customer Request Organizational Need Legal Requirement Technological Advance Posición de un proyecto en la organización: Strategy -> Program -> Project -> Subprojects Performing Organization?

7 Project Management (key) Stakeholders Customers/Users Sponsor
Functional Manager Project Manager Influencers PMO Project Management Team Project Team

8 Project Management Organizationional Structures:
Quien ejerce la coordinación de los proyectos El Gerente Funcional o un Gerente del Proyecto

9 Project Management Organizational Structures:
Pueden existir combinaciones: Que tienden a ser funcionales u orientadas a proyectos

10 Project Management Organizational Structures:
Lo más sano para la organización es que la autonomía se encuentre balanceada.

11 Project Management Organizational Structures:

12 Project Management Elementos de PMI (2004): 5 Process Groups
9 Process Areas 44 Processes

13 Project Management

14 Mejoramiento Continuo = Plan-Do-Check-Act
Project Management Mejoramiento Continuo = Plan-Do-Check-Act

15 Project Management

16 Project Management

17 Project Management

18 Project Management

19 Project Management

20 Project Management

21 Project Management

22 Project Management Administración de Riesgos Proceso
Clasificación de Riesgos Lista de Riesgos Planes de Administración

23 Project Management Administración de Riesgos Proceso

24 Project Management Administración de Riesgos Clasificación de Riesgos

25 Project Management Administración de Riesgos Lista de Riesgos

26 Project Management Administración de Riesgos Planes de Administración

27 Project Management

28 Project Management

29 Project Management

30 Project Management Actividades de Inicio:
Se desarrolla en comienzo, en un contexto externo al proyecto. Tiene como objetivos: Analizar y documentar el problema organizacional a ser resuelto por el producto del proyecto (Business Modeling). Evaluar la viabilidad del proyecto. Determinar la información básica necesaria para iniciar la planeación del proyecto. = Scope Statement Formalizar el inicio del proyecto = Project Charter

31 Project Management Actividades de Inicio: Business Modeling
Técnicas de Selección de Proyectos Tipos de Contratos Pet Projects Deliverables Project Charter Scope Statement

32 Project Management Actividades de Inicio: a. Business Modeling:
Se realiza un análisis de causas para entender a detalle el origen del proyecto. Si se identifican temas no resueltos, deben resolverse en esta etapa. Se debe documentar toda la información necesaria para iniciar el proyecto. Se deben evaluar de forma integral las implicaciones y el impacto del producto del proyecto para la organización.

33 Project Management Actividades de Inicio: b. Técnicas de Selección:
El proyecto debe estar alineado con los objetivos de la organización (partir del plan estratégico). La viabilidad del proyecto debe determinarse de forma integral: Técnica: ¿Es viable técnicamente realizar el producto del proyecto en el tiempo y costos estimados? Funcional: ¿En que se beneficia el negocio de la organización? Entorno Externo a la organización: Mercado / Industria de la organización Dentro de la Organización: ¿En este instante se encuentra la organización preparada para el proyecto y su producto bajo todas las implicaciones? Administrativa (Q, S, t, $, Risk-Thresold)

34 Project Management Actividades de Inicio: c. Tipo de Contrato:
El tipo de contrato debe identificarse de acuerdo con el nivel de viabilidad del proyecto dentro de la industria en que se desarrolla: Existen herramientas estables que simplifican en gran medida el desarrollo del producto del proyecto?. El producto del proyecto ya existe en el mercado?, debe ser adaptado a las necesidades particulares de la organización?. Existe vasto conocimiento y experiencia en el tipo de proyecto?. El nivel de riesgos es mínimo en todas las dimensiones del proyecto? (administrativa, funcional, técnica). Desafortunadamente la selección del tipo de contrato se realiza por factores culturales. Para la industria de Software el tipo de contrato recomendado es de Subcontratos / Fases o Subcontratos / Versiones. El tipo de contrato determina el éxito del proyecto antes de que este comience.

35 Project Management Actividades de Inicio: d. Pet Projects: Seleccionar e invertir en desarrollar un proyecto no-viable. e. Project Charter: Artefacto que representa la autorización e inicio formal del proyecto. f. Scope Statement: Compendio de alto nivel del alcance del proyecto.

36 Project Management Inicio del Proyecto: Conocer y dimensionar el problema evaluando su viabilidad. Documento de Visión Project Charter = Autorización del inicio del proyecto o Fase Scope Statement (RFP): Dimensión Técnica Dimensión Funcional Dimensión Administrativa y de Soporte Técnica de Selección: Selección Integral = Scoring Model

37 Project Management Toma de Decisiones Se debe basar en una
metodología que evite conflictos de intereses personales como Weighted Scoring Model: Identifique los factores que intervienen en la decisión y asigneles en consenso un peso o prioridad Asigne un puntaje a cada factor Sume el total de cada alternativa. Se escoge la alternativa con mayor puntaje acumulado Criterio Peso Keel Mule JBI-SDK Celtix ServiceMi Tipo Herramienta 0,2 0,6 1 0,4 Release estable Se basa en tecnologías WS Profundidad Documentación 0,1 0,5 Enrutamiento e invocación dinámica de servicios web Procesamiento Síncrono / asíncrono 0,25 Incluye implementaciones de ServiceProviders / Handlers 0,3 TOTAL 2,2 3 3,4 3,65 4,6

38 Project Management Criterio Peso Proyecto 1 Proyecto 2 Proyecto3
Toma de Decisiones: Caso Asignación Integrada de Recursos Criterio Peso Proyecto 1 Proyecto 2 Proyecto3 Incumplimiento Contractual 40% 1.6 0.4 2 Dificultad Reemplazo por otro recurso del equipo/unidad 20% 0.2 0.6 1 Margen de atraso para la actividad 0.8 Nivel de dedicación Requerida 0.5 TOTAL 100% 3.1 2.2 5

39 Project Management Inicio del Proyecto: Project Scope Statement Industria del Software: Dimensión Técnica Subsistemas y módulos Módelo Entidad Relación Req. No Funcionales / Técnicos / Arquitectónicos Dimensión Funcional Req. Funcionales: Modelo de Casos de Uso + Reglas de Negocio (D. Actividades) Req. Suplementarios / Adicionales / Complementarios Dimensión Administrativa y de Soporte Documento de Visión + Project Charter Condiciones Contractuales Condiciones Económicas Condiciones Técnicas (Experiencia, Metodologías, Certificaciones)

40 Project Management Actividades de Planeación:

41 Project Management Project Plan: HR Mgmt Plan Comm Mgmt Plan
Quality Mgmt Plan (QA+QC) Scope Mgmt Plan (WBS) Time Mgmt Plan (Schedule) Risk Mgmt Plan Procurement Mgmt Plan Cost Mgmt Plan (Budget) * 5,6,7 depends on 4 (WBS)

42 Project Management Actividades de Planeación:
Estrategias de Planes de Proyecto Super-plan (proyectos pequeños max 20 hojas) 1 Plan Maestro – N subplanes X Áreas de Conocimiento 1 Plan Maestro – 4 subplanes X Fases RUP 1 Plan Maestro – 4 subplanes X Fases RUP (cada uno contiene las 9 áreas de conocimiento)

43 Project Management Actividades de Planeación:
Human Resources Mgmt Plan Roles y Responsabilidades: Según fase del proyecto y entregables (área de conocimiento) Estrategia selección equipo de trabajo Perfil Psicológico acorde al Rol Test de Conocimientos Lógica de Programación Precisión (select) Optimización de código Dominio del Lenguaje de Programación Aptitudes de Diseño (Patrones aplicados a un problema) Evaluación de Experiencia y Certificaciones

44 Project Management Actividades de Planeación: Communication Mgmt Plan
Especificación formal de la interacción entre los involucrados en el proyecto Se debe definir según el tipo y cultura de la organización. Roles Requeridos (Sponsor, FunctionalManager, Technical Users, Functional Users) Mecanismos de Comunicación: Formales Informales Reuniones de Seguimiento (administrativas, técnicas, funcionales) Mecanismos de Revisión Mecanismos de Aceptación / Plan de Aceptación (entregables y resultados de pruebas). Por semana, iteración y fase. Reglas del Equipo

45 Project Management Actividades de Planeación: Procurement Mgmt Plan
Licencias Software Compra o Arriendo de Hardware: Recursos Humanos: Consultorías Adicionales Servicios – Taxis y comida (horas extras???)

46 Project Management Actividades de Planeación: Risk Mgmt Plan
Riesgos Administrativos (9 áreas PMI) Está controlado el alcance Existen limitaciones de $ t Revise la normatividad que legisla el proyecto, la organización y el país Existen mecanismos de comunicación, revisión y aceptación En que medida se garantiza el éxito de los Riesgos Funcionales Riesgos Técnicos

47 Project Management Actividades de Planeación: Quality Mgmt Plan
Quality Assurance Como implantará la metodología de Gerencia en el proyecto ? Como implantará la metodología de Desarrollo en el proyecto ? Factores de apoyo como certificaciones y experiencia en el mismo dominio de negocio (tipo de industria) Quality Control: Plan de Pruebas Predefina los objetivos de calidad en cada fase del proyecto Establezca como va a medir la calidad (tipos y criticidad de defectos) Hallazgos vs. Defectos Seleccione tipo de pruebas según riesgos identificados Evalúe en que momento, como y hasta donde probar? Que recursos se necesitan para realizar el plan de pruebas? (de la organización y el proyecto)

48 Project Management Actividades de Planeación: Scope Mgmt Plan
WBS (actividades / Entregables / área de conocimiento) Lista de Actividades - > Análisis de Dependencias y trabajo paralelo Que es un caso de uso? Controlar por Pantallas 1(1 día) – 5(4 semanas) Delimite los objetivos a fechas de cierre Requerimientos Diseño Desarrollo Pruebas Predefina etapas y políticas de revisión y ajuste al final de cada fase

49 Project Management WBS - Work Breakdown Structure

50 Project Management WBS - Work Breakdown Structure

51 Project Management

52 Project Management

53 Project Management Actividades de Planeación: Time Mgmt Plan
Debe ajustarse según compromisos y dependencias de las actividades. Análisis de Ruta Crítica = Dependencias funcionales de Módulos/Casos de Uso RUP trae implícitas las técnicas de Fasttracking (entregas parciales iterativas) y Crashing (trabajo en paralelo). Afecta directamente al costo

54 Project Management Actividades de Planeación: Cost Mgmt Plan
Objetivo, el presupuesto Costos Directos vs. Indirectos Costos por área de conocimiento No se le olvide pesar los riesgos y la holgura de tiempo como factores directamente proporcionales

55 Project Management Actividades de Ejecución:

56 Project Management Actividades de Ejecución:
Todas las actividades (herramientas, técnicas y procesos) propios a desarrollar el producto del proyecto. Las actividades de este grupo no se detallan en PMI. Son particulares a la industria en la que se desarrolle el producto del proyecto. Para la industria de software el compendio más completo de procesos de desarrollo son los derivados de la metodología del Proceso Unificado.

57 Project Management Actividades de Monitoreo y Control:

58 Project Management Actividades de Monitoreo y Control:
Generación periódica de reportes e informes de avance del trabajo del proyecto. El PM analiza y evalúa el progreso real del proyecto vs. los estimados planeados. Se monitorea, controla y actualiza constantemente el estado de los riesgos del proyecto. Consecuentemente, se detectan y gestionan controles de cambio.

59 Project Management Presentación EVA

60 Project Management Actividades de Cierre:

61 Project Management Actividades de Cierre:
Finalización de todas las actividades Puede ser por finalización del producto o por cancelación del proyecto. Cierre Administrativo. Verificación del producto entregado, documentación de las lecciones aprendidas y actualización de los procesos relacionados. Cierre Contractual. Obtener la firma y aprobación formal del cliente para terminar el proyecto. De ser necesario esta etapa podría incluir litigar temas pendientes para cerrar todos los contratos del proyecto.

62 Project Management Ejemplos y Formatos

63 Conclusiones La gestión de la comunicación es débil, o peor, inexistente en nuestro medio lo que directamente afecta el alcance y entendimiento entre proveedor y cliente. La gestión de la comunicación debe adaptarse según la cultura organizacional del cliente. El éxito del proyecto parte de la evaluación de su viabilidad (administrativa, técnica y funcional) antes de iniciarlo.

64 Conclusiones Es responsabilidad del Gerente Funcional del cliente previamente evaluar la viabilidad del proyecto y proveer toda la información administrativa, técnica y funcional a los proveedores. En software la mejor alternativa Win-Win para tipos de contratos es un híbrido entre T&M/FP = Contrato Marco y Subcontratos (por fases del proyecto). El éxito administrativo en gestionar el alcance se basa en: Evaluación de la Viabilidad Plan de comunicación Plan de Gestión de Cambios Plan de Aceptación Administración de riesgos Precondiciones y restricciones contractuales, etc.

65 Conclusiones El éxito funcional en gestionar el alcance se basa en una adecuada ingeniería de requerimientos. El éxito técnico en gestionar el alcance se basa en tener un conocimiento detallado de la plataforma tecnológica frente a las necesidades del producto. En nuestro medio las empresas proveedoras difícilmente realizan gestión de recursos humanos ya que estos solo se contratan (y rotan) por proyecto. La administración de riesgos es el tema central de las reuniones entre cliente y proveedores desde el inicio al final del proyecto. Los riesgos se pueden gestionar y por tanto comunicar según su grupo: Administrativos Funcionales Técnicos

66 Conclusiones En la práctica, es un estándar de facto el uso de la herramienta WBS para identificar progresivamente las actividades necesarias para realizar los entregables principales y secundarios del proyecto. En la industria del software se recomienda organizar un WBS según elementos de RUP: Nivel 1. Fase Nivel 2. Disciplina RUP Nivel 3. Entregables. Nivel 4. Macro Actividades Del WBS se puede deducir el cronograma, presupuesto, lista de riesgos El esfuerzo final de la planeación es el presupuesto pero este se deduce principalmente del cronograma (actividades+tiempo+recursos). En nuestro medio no es común que el presupuesto incluya gestión de costos indirectos, costo del riesgo y de la holgura del proyecto.

67 Conclusiones Según los riesgos del proyecto, la holgura total en tiempo es aprox (10% - 30%) Los contratos a precio fijo son los que más riesgos tienen, por lo que es común que el costo neto ($/hour-man) se multiplique por 3. Regla del 80/20. Adicionalmente asumimos que realizamos una planeación con precisión del 80% por lo que se añade al total un 20% en tiempo.

68 Conclusiones Es recomendable que el Plan del Proyecto se “vea” como un plan de alto nivel (plan maestro) que integra los subplanes de las 8 áreas de procesos de PMI. Se recomienda que el plan de gestión de la calidad se estructure en 2 grupos: QA: Subplan de Aseguramiento de Calidad (estrategia de implantación de las buenas prácticas de forma particular al proyecto). QC: Subplan de Control de Calidad (Metodología de revisiones y pruebas). Las herramientas y técnicas más usadas son: WBS EVA Weighted Scorecard Model

69 Conclusiones El equipo del proyecto debe gestionarse partiendo de la premisa de que todo el staff del cliente es parte vital de él. Finalmente el proyecto lo ejecutan las personas que lo conforman (cliente-proveedor). Por lo anterior nunca será suficiente en invertir y mejorar las habilidades de comunicación y administración del recurso humano.

70 Muchas Gracias por su tiempo !!!
Finalmente… Muchas Gracias por su tiempo !!!