DEC-SHCP DIPLOMADO EN GESTION E IMPLEMENTACION DE TECNOLOGÍAS DE INFORMACIÓN Y COMUNICACIÓN MÓDULO 4: IMPLANTACIÓN Y PRODUCCIÓN DE PROYECTOS DE TI L.I. PMP Saúl Rodríguez Saud AGENDA •Conceptos • Qué es un Proyecto • Ciclo de Vida del Projecto • Proyecto y Producto • Administración de Proyectos • ITSM • Gestión de Servicios WHAT ARE PROJECTS? 3 PROJECTS ARE….. Temporary and one-time endeavor undertaken to create a unique product or service. Un esfuerzo temporal llevado a cabo con el fin de crear un producto o servicio único. Carefully selected set of activities chosen; • To use resources - People, Time, money, materials, energy, space, provisions, communication, quality and risk to meet the predefined objectives. 4 THE FOUR PROJECT DIMENSIONS People Process Product Technology 5 TREE PROJECT OBJETIVES Performance Cost Time PROJECT PHASES All projects are divided into phases All phases together are known as the Project Life Cycle Each phase is marked by completion of Deliverables 7 WHY DO PROJECTS SUCCEED? Executive support User involvement Experienced project manager Clear business objectives Minimized scope Standard software infrastructure Firm basic requirements Formal methodology Reliable estimates 8 WHO ARE STAKEHOLDER? 1. Function Representative 2. Executive Sponsor 3. Project Manager 4. And … 9 MODELOS DEL CICLO DE VIDA DE UN PROYECTO 1 CICLO DE VIDA DE UN PROYECTO Es la forma en la que se divide un proyecto en etapas y cómo se avanza entre estas etapas Según la metodología hay varios modelos, pero analizaremos los siguientes: En cascada Orientado a hitos Orientado a prototipos Programación extrema MODELO EN CASCADA (I) Especificación de requisitos Análisis Diseño Codificación Pruebas Implantación Mantenimiento Es el modelo clásico Las fases se deben ejecutar de forma secuencial, pero se puede volver a la fase anterior Cada etapa genera una documentación o un producto que recibe de entrada la siguiente fase MODELO EN CASCADA (II) Objetivo de cada una de las etapas: Especificación de requisitos: Documento con la especificación de requisitos (ERQ) Análisis: Documento de análisis funcional Diseño: Documento de diseño técnico Codificación: Código fuente de la aplicación y manuales de usuario Pruebas: Documentación de pruebas Implantación: Documento de operación MODELO EN CASCADA (III) Ventajas Minimiza la repetición de tareas de desarrollo La planificación es sencilla Facilita el control, permitiéndonos afrontar proyectos grandes Inconvenientes Solo es adecuado cuando hay requerimientos muy bien definidos y que no van a cambiar Retroceder para corregir fases previas o introducir cambios es muy costoso El cliente sólo ve los resultados al final MODELO ORIENTADO A HITOS (I) Especificación de requisitos Análisis Diseño de arquitectura Consiste en introducir hitos entregables al cliente durante el desarrollo del proyecto Codificación y pruebas A Entrega A Codificación y pruebas B Entrega B Codificación y pruebas C Entrega C MODELO ORIENTADO A HITOS (II) Ventajas El cliente va viendo los resultados Permite reducir mucho el riesgo en proyectos grandes si se gestionan sus módulos de menor prioridad con esta técnica Inconvenientes Se analiza todo el sistema al principio, y se puede perder mucho tiempo en la especificación y diseño de funcionalidades que al final no nos da tiempo a implementar MODELO ORIENTADO A PROTOTIPOS (I) Prototipo 1 Prototipo 2 Prototipo 3 Se desarrolla un primer prototipo relativamente completo, frecuentemente destinado a ser ya utilizado por cliente. El cliente aporta realimentación y con ella se desarrolla el siguiente prototipo Se van repitiendo los ciclos de iteración hasta alcanzar una versión final. MODELO ORIENTADO A PROTOTIPOS (II) Ventajas Es muy frecuente que los requisitos sean cambiantes, con lo cual se van adaptando los prototipos El cliente ya puede ir trabajando con los prototipos, viendo el resultado y aportando feedback Inconvenientes En proyectos grandes es imposible saber cuando se terminará Los desarrolladores tienen a saltarse las fases de análisis y diseño PROGRAMACIÓN EXTREMA (I) Consiste en llevar la límite el modelo de prototipos, haciendo entregas continuas con pequeños cambios en la funcionalidad PROGRAMACIÓN EXTREMA (II) Sus principios fundamentales son: Desarrollo iterativo e incremental Pruebas unitarias continuas Programación en parejas Frecuente interacción con el usuario Corrección de todos los errores antes de añadir nueva funcionalidad Hacer entregas frecuentes Refactorización del código Propiedad del código compartida Simplicidad en el código PROGRAMACIÓN EXTREMA (III) Ventajas Es muy realista con respecto a la relación con el cliente Le da importancia el diseño simple y las pruebas, un punto normalmente descuidado Aporta muy buenas ideas Inconvenientes Solo vale para proyectos relativamente pequeños (entre 2 y 12 desarrolladores) Sus principios no pueden ser aplicados a en todos los casos, es necesario saber decidir cuando aplicar ciertas cosas y cuándo no PROYECTO VS PRODUCTO ALCANCES… Alcance del Producto: Son los requerimientos relacionados con el producto objeto del proyecto; es el contestación a la pregunta: “Cual es el resultado final esperado” Alcance del Proyecto: Es el trabajo que el proyecto debe hacer para entregar el producto objeto del proyecto. CICLO DE VIDA Ciclo de vida del Producto: Son los pasos que llevan a un producto de su concepcion hasta su desuso: Concepción, Crecimiento, Madurez, Decline, Desuso CICLOS DE VIDA Ciclo de vida del proyecto: Según PMI se necesitan 2 metodologías para completar un proyecto de IT: Project life cicle : Son los pasos necesarios para completar el proyecto: High level Design,detailed desing, coding, testing, installation, conversion & turnover to operations Project Management Process: Los pasos para la gestión del proyecto:Initiating, Planning, Executing, Monitor & Controlling, Closing ENTONCES.. Concepción Crecimiento Madurez Proyecto 1 Proyecto 3 Proyecto 5 Proyecto 2 Proyecto 4 Proyecto 6 Una fase del ciclo de vida de producto puede requerir u o o mas proyectos y cada proyecto incluye los ciclo del vida del proyecto ADMINISTRACION DE PROYECTOS ADMINISTRACION DE PROYECTOS: PM:Es la forma de como gestionar un proyecto de principio a fin utilizando 9 areas de conocimiento a travez de 5 procesos Programa: Es un conjunto de Proyectos que se coordinan es conjunto para hacer más eficiente su gestión. Portafolio: Es un conjunto de programas relacionados directamente con metas estratégicas de la organización PMO: Centraliza la gestión de los proyectos de la organización, provee politicas y metodologías ha usar , además de dar soporte y guia de como administrar proyectos, y provee los PM necesarios para cada proyecto. ADMINISTRACIÓN POR OBJETIVOS Establecimiento de objetivos realisticos y sin ambigüedades Evaluar periodicamente si los objetivos fueron alcanzados Implementar acciones correctivas RESTRICCIONES DEL PROYECTO Constraints Cost Scope Quality Customer Sat Risk Resources Time ESTRUCTURAS ORGANIZACIONALES Funcional Projectizada Matricial (fuerte, debil,balanceada) PMO Codificación Infraestructura Finanzas Interfases PM Front end Admon Servers Admon BD HD Diseño PMO Codificacion Infraestructura 9 AREAS DE CONOCIMIENTO 32 PROCESOS DE LA ADMON DE PROYECTOS Initiating Processes Planning Processes Controlling Processes Executing Processes Closing Processes AREAS DE CONOCIMIENTO / PROCESOS Donde esta Liberación a Producción y producción ? ITSM IT SERVICE MANAGEMENT IT Service Management Increase IT Service Quality Business Alignment Decrease IT Costs Do More With Less Delivering IT Services that meet customer service level requirements at a justifiable cost 37 ITERATIVE PROCESS How do we keep the momentum going? What is the vision? High Level Objectives Where are we now? Assessments Where do we want to be? Measurable Targets How do we get there? Process Improvements How do we check we got there? Measurement And Metrics 38 ITIL SERVICE MANAGEMENT (V2) Service Management is the best known and most mature aspect of ITIL. It is comprised of two volumes: Service Support and Service Delivery. Service Management Service Support Service Delivery • Service Desk • Incident Management • Problem Management • Configuration Management • Change Management • Release Management • Service Level Management • Financial Management • Availability Management • Continuity Management • Capacity Management The Service Support Process Model – Pink Elephant The Business, Customers & Users Management Tools Difficulties Queries, Enquiries Incidents Incidents Incident Service Desk Communication Updates Work-arounds Changes Problem Service Reports Incident statistics Audit Reports Problem Statistics Trend Analysis Problem Reports Problem Reviews Diagnostic Aids Audit Reports Incidents Releases Change Change Schedule CAB Minutes Change Statistics Change Reviews Audit Reports Release Release Schedule Release Statistics Release Reviews Secure Library Testing standards Audit Reports Configuration CMDB Reports CMDB Statistics Policy/Standards Audit Reports CMDB Problems Known Errors Changes Releases CIs Relationships THE TRINITY Change Management Is the set of standardized processes and tools used to handle change requests in order to support the business while managing risks. [Risk Management] Release Management Uses formal controls and processes to ensure requirements are met and safeguard the production environment. [Quality Management] Configuration Management Focuses on tracking and documenting configurations and then providing this information to other areas including Change and Release Management. [A combination of Knowledge Management and Information Broker] The three process areas must work together and share information. How are ITIL V2 Processes Being Adopted? Source> Hornbill 48 48 © 2009 IBM Corporation ITIL VERSION 3 ITIL VERSION 3 LOOKS AT THE LIFECYCLE OF IT Service improvement Requests for change Guidelines , policies , and information for Service Desk to support incidents Usage guidelines , policies , and incentives to change utilization patterns Service transition How service is utilized Requests for change How service is supported Possible service incidents Service design How service is deployed Service operation How service is delivered (Filtering) Design limitations Requests for change Requests for change Objectives , policies and guidelines Service strategy Compensating resources and requests for change ITIL V3 BOOKS Service Strategy The spoke of the IT Service Management wheel. Provides the direction and vision for establishing IT services. Useful for influencing organizational attitudes and culture towards the creation of value for customers. The goal of service strategy: “Superior performance versus competing alternatives.” ITIL V3 BOOKS Service Design Responsible for the design of new or changed services going into a live environment. Ensure designs are consistent, compatible and capable. Metrics definition, selection and evaluation of measurement capabilities. Evaluation and establishment of policies/procedures for new or changed services. Key output of Service Design – Design solutions to meet the changing requirements of the business. ITIL V3 BOOKS Service Transition Plan and manage the capacity and resources required to package, build, test and deploy into production. Provide a consistent and rigorous framework for evaluating risk. Ensure that services can be managed, operated and supported as specified from Service Design. Communication and documentation of information for decision making and deployments into production. ITIL V3 BOOKS Service Operation Coordinating and carrying out the activities and processes required to deliver and manage services at agreed levels. Focuses on: Event Management Incident and Problem Management Request Fulfillment Service Operation is where actual value is seen by customers/users of a service. ITIL V3 BOOKS Continual Service Improvement Align and realign IT services to changing business needs by identification and implementation of improvements. Review, analyze and make recommendations for each stage of the service lifecycle (strategy, design, transition and operation). Review service level achievements. Establishing Service Improvement Plans (SIP) to improve service performance and to identify financial and customer benefits. Continuous Service Improvement Processes Service Strategy Processes Service Transition Processes Service Design Processes Service Operation Processes Demand Management Strategy Generation Service Portfolio Management IT Financial Management Service Measurement Service Catalogue Management Service Level Management Capacity Management Availability Management Service Continuity Management Information Security Management Supplier Management Transition Planning and Support Service Reporting Change Management Service Asset and Configuration Management Release and Deployment Management Service Validation and Testing Evaluation Knowledge Management Event Management Incident Management Service Improvement Request Fulfillment Problem Management Access Management Operation Management SERVICE LEVEL MANAGEMENT BALANCE Business Objectives IT Objectives Customer Objectives WHAT LEVEL OF SERVICE SHOULD IT DELIVER? Service – “A set of related functions provided by IT that are seen by the customer as a self-contained entity” • What services does your IT organization provide? • How many services do you provide? Ted Levitt of Harvard Business School identified four levels of service GENERIC – The most basic level of service EXPECTED – The level of service which a customer has come to expect from a specific supplier GENEROUS – this level of service offers more than the customer expects at that price TOTAL – The highest possible level of service IMPLEMENT SERVICE LEVEL MANAGEMENT - Determine what the Customer “Needs” - Our role is to translate what the customers “want” into what they “need” - Never say “NO” ……give them a price -Produce the Service Level Requirements document which describes IT Services in terms that the Customer understands -Internal and External Documents IMPLEMENT SERVICE LEVEL MANAGEMENT Internal and External Documents – Internal Spec Sheets • Specify what IT must do to meet the needs of the customer • This is a technology view • Internal and external IT Suppliers • Written in terms that IT understands • The sum of the commitments must meet the specified availability External Spec Sheets • What the Customer wants : “expected” levels of service from IT Written in terms the Customer understands IMPLEMENT SERVICE LEVEL MANAGEMENT Service Level Agreements - Underpinned by OLAs and UCs – Written in customer terms - Describes IT Services - Describes service hours, availability, mean time between failures, mean time to repair -Not a listing of penalty clauses Operating Level Agreements - Formal agreements between the IT departments -KPIs aligned to the Internal Spec Sheets – Written in technical terms Underpinning Contracts - Formal contracts with external suppliers - Legal documents - KPIs aligned to the Internal Spec Sheets – Written in technical terms
