PLANEAMIENTO ESTRATÉGICO

EN INFORMÁTICA
 CARACTERÍSTICAS DE UN PROYECTO

Un proyecto estará sujeto a múltiples restricciones como, entre otras:

• La duración o fecha prevista de finalización;
• La disponibilidad de presupuesto;
• La disponibilidad de recursos;
• Los factores relacionados con la salud y la seguridad del personal;
• El nivel aceptable de exposición al riesgo;
• El potencial impacto social o ecológico;
• Las leyes, los reglamentos y otros requisitos legales.
 CARACTERÍSTICAS DE UN PROYECTO

• Temporalidad: Tienen una duración limitada, con un comienzo y un final definidos.

• Entregables: Crean entregables únicos
• Objetivo: Generalmente es el propio entregable
• Contexto: Pueden ser de larga duración y estar sujetos a influencias externas e
internas.
• Restricciones: Pueden ser de distinta naturaleza.
• Riesgo e incertidumbre: Siempre presente en mayor o menor grado.
• Ciclo de vida: Se desarrolla por etapas, comenzando por una fase de definición y
haciéndose más explícito y detallado a medida que el equipo de proyecto
desarrolla un mejor y más completo entendimiento de los objetivos y de los
productos entregables.
CICLO DE VIDA
CICLO DE VIDA
 CICLO DE VIDA
PRODUCTO - PROYECTO
 ¿QUÉ ES LA GESTIÓN DE PROYECTOS?

• Ideas fundamentales:
• Un conjunto de conocimientos, métodos, herramientas,
técnicas y competencias: La Gestión de Proyectos no es un
proceso absolutamente definido.
• Requisitos: El proyecto tiene un cliente que podrá ser
interno o externo.
Como ya se ha señalado, la Gestión de Proyectos se lleva a
cabo mediante procesos; los procesos seleccionados para
desarrollar el proyecto deben enfocarse desde un punto de
vista sistémico.
 BENEFICIOS DE UNA EFICAZ
GESTIÓN DE PROYECTOS
• Ahorros de tiempo y coste:
• Más rapidez en la resolución de problemas:
• Optimización en la resolución de riesgos: Mayor efectividad
en la comunicación y gestión de expectativas:
• Mayor calidad de productos y servicios: Optimización de la
gestión financiera:
• Mejora del proceso de toma de decisiones:
• Mejora del ambiente laboral:
CONTEXTO DE LA DIRECCIÓN Y
GESTIÓN DE PROYECTOS
PROYECTOS, PROGRAMAS Y
CARTERAS DE PROYECTOS
ESTRUCTURA ORGANIZATIVA
ESTRUCTURA ORGANIZATIVA
ESTRUCTURA ORGANIZATIVA
ESTRUCTURA ORGANIZATIVA
 OFICINA DE DIRECCIÓN DE
PROYECTOS (PMO)
•
• La Oficina de Dirección de Proyectos es una estructura de gestión
que estandariza los procesos de gobernanza relacionados con el
proyecto y posibilita compartir recursos, metodologías, herramientas y
técnicas.
 INTERESADOS
Los Interesados del proyecto, traducción del extendido término en lengua inglesa
“stakeholders”, son todas aquellas personas u organizaciones, tanto internas como
externas, cuyos intereses pueden verse afectados como consecuencia del desarrollo
del proyecto.
Reglas básicas:
• Identificar y relacionar a todos los Interesados: si aparecen otros nuevos con el
proyecto ya iniciado podrían solicitar cambios y ello tendría consecuencias en
tiempo y en dinero.
• Determinar su interés, necesidades y expectativas, para transformarlos en requisitos
del proyecto.
• Crear una matriz de Interesados que refleje la influencia e interés de cada uno de
ellos. Esta matriz facilita la toma de decisiones y la forma de gestionar a los
Interesados en función del lugar que ocupen en la misma.
• Comunicarse con ellos.
• Siempre que sea posible, gestionar su influencia en relación con los requisitos, como
forma de alcanzar un proyecto exitoso.
INTERESADOS
AGENTES INTERESADOS
DE UN PROYECTO
 ANTECEDENTES DE LA
GESTIÓN DE PROYECTOS
• Ya en 1916 el ingeniero francés Henry Fayol había publicado su obra “Administration
industrielle et générale”, en la que describía las seis funciones de gestión que
constituían la base del cuerpo de conocimientos relacionados con la gestión de
equipos humanos en empresas y proyectos.
• Pero la primera gran innovación en la Gestión de Proyectos como disciplina tiene
lugar en 1917 cuando Henry Gantt desarrolla el diagrama de programación que lleva
su nombre. Uno de los primeros usos del Diagrama de Gantt fue en el proyecto de la
presa Hoover, que comenzó en 1931.
• En 1936 Alain Turing desarrollaba la Máquina de Turing, que describía el
funcionamiento lógico de una CPU.
• En 1939 Walter Shewhart, conocido como “El padre de la calidad”, proponía el
proceso de mejora continua a través del ciclo PDCA (Planear-Hacer-Comprobar-
Actuar) que, posteriormente, sería difundido por Deming.
• En 1948 Taiichi Ohno inventaba el método Kanban en Toyota: el Lean Manufacturing
se constituiría en precursor del movimiento ágil.
• En 1956 se constituía la American Association of Cost Engineers, actualmente
denominada AACE International. Sería en esta década cuando las empresas
comenzarían a aplicar de forma sistemática las herramientas y técnicas propias de la
gestión de proyectos.
 ANTECEDENTES DE LA
GESTIÓN DE PROYECTOS
• En 1957 Dupont Corporation había desarrollado el Método del Camino Crítico (Critical
Path Method, CPM).
• En 1958 la Oficina de Proyectos Especiales de la Armada norteamericana inventaba la
técnica PERT (Program Evaluation Review Technique) para el desarrollo de su proyecto de
submarino Polaris. En el marco de este mismo proyecto, el Departamento de Defensa de
Estados Unidos creaba el concepto de Estructura de Desglose de Trabajo, EDT, (Work
Breakdown Structure, WBS)
• que publicaría en 1962 para su uso en posteriores proyectos. Cincuenta años atrás, el
ingeniero y economista norteamericano Frederick Taylor ya había introducido dicho
concepto en su obra “The Principles of Scientific Management”.
• En 1965 se fundaba la organización IPMA (International Project Management Association).
• En 1969 cinco voluntarios fundaban el PMI (Project Management Institute) como una
organización profesional sin fines de lucro dedicada a promover la práctica, la ciencia y
la profesión de gestión de proyectos. Ese mismo año nacía el paradigma de
Programación Estructurada.
• En 1970 el ingeniero americano Wiston Royce introducía las bases del modelo de
desarrollo en cascada en su artículo “Administrando el desarrollo de grandes sistemas de
software”.
• En esta misma década Tom Gilb publicaba los conceptos relativos a la Gestión Evolutiva
de Proyectos, mientras que en 1974 Ernest A. Edmonds presentaba el “Proceso de
Desarrollo de Software Adaptativo”.
 ANTECEDENTES DE LA
GESTIÓN DE PROYECTOS
• En 1975 la empresa Simpact Systems Limited creaba el método PROMPT II (Project
Resource Organization Management Planning Techniques) como un intento de
establecer las directrices para el flujo de fase de un proyecto de equipo. Ya en 1979
la Agencia Nacional de Computación y Telecomunicaciones (CCTA) del Reino Unido
adoptaría este método para todos los sistemas de información de los proyectos.
• Previamente, en 1975 Fred Brooks había publicado el libro “The Mythical Man- Month:
Essays on Software Engineering”. Este libro de ingeniería de software y gestión de
proyectos, se centraba en la idea de “la adición de mano de obra para un proyecto
de software que está retrasado, lo demorará aún más”.
• En 1986 aparecía el primer registro del término Scrum como una metodología para la
Gestión de Proyectos.
• En 1987 el PMI publicaba la Guía PMBOK® como un libro blanco para documentar y
estandarizar la información y prácticas aceptadas para la gestión de proyectos.
• En 1989, la Subsecretaría de Defensa para Adquisiciones de Estados Unidos
incorporaba la Gestión del Valor Ganado (Earned Value Management, EVM) como
una parte esencial de sus programas y compras.
• En 1992 Alistair Cockbur presentaba los métodos Crystal, el punto de inicio de la
evolución de las metodologías de desarrollo de software que desembocaron en lo
que hoy se conoce como el movimiento ágil.
 ANTECEDENTES DE LA
GESTIÓN DE PROYECTOS
• En 1995 Ken Schwaber y Jeff Sutherland presentaban el método Scrum en la
conferencia OOPSLA (Object-Oriented Programming, Systems, Languages
and Applications) 95 de Texas.
• La agencia británica CCTA publicaba en 1996 PRINCE (PRojects IN Controlled
Environments), como una evolución del método PROMPT II.
• En 1997 veía la luz el libro “La Cadena Crítica”; en él su autor, Eliyahu M. Goldratt,
presentaba el concepto de la Gestión de Proyectos por Cadena Crítica (CCPM).
• En 1998 el American National Standards Institute (ANSI) reconocía el PMBOK® como
un estándar.
• En 1999 Jim Highsmith formalizaba el concepto de Desarrollo de Software Adaptativo
y publicaba un libro con el mismo nombre. La idea evolucionaría hacia las
metodologías de Desarrollo Rápido de Aplicaciones (RAD). Ese mismo año Kent Beck
introduce la metodología de desarrollo Extreme Programming (XP), el empleo de User
Stories, la Integración Continua, Pair Programming y otras prácticas usadas
ampliamente en el desarrollo ágil.
• En 2001 Bob Martin reunía a otros 16 líderes del movimiento ágil para redactar el
“Manifiesto Ágil”; este Manifiesto, con cuatro valores y doce principios, englobaba
aquellas metodologías que hasta ese momento eran conocidas como “Metodologías
de desarrollo de software de peso liviano”.
 ANTECEDENTES DE LA
GESTIÓN DE PROYECTOS
• En 2003 Mary y Tom Poppendieck publicaban el libro “Lean Software Development”
llevando los principios de Lean al desarrollo de software.
• En 2006 la citada asociación americana AACE Internacional presentaba el “The Total
Cost Management Framework” (Marco para la Gestión de Costes Totales), primer
marco de procesos integrados para portfolios, programas y gestión de proyectos.
• En 2007 David Anderson presentaba su obra “Kanban”, adaptando el método
Kanban para el desarrollo de software. Dicho método se enfocaba en la entrega
“justo a tiempo” y en no sobrecargar a los desarrolladores de software.
• En 2008 se publicaba la cuarta edición del PMBOK®.
• La Office of Government Commerce (OGC) del Reino Unido realiza en 2009 una
revisión profunda de la metodología PRINCE, conocida como PRINCE2®.
• También en 2009 Eric Ries escribía su obra “Lean Startup”. Se trata de una
metodología para el desarrollo de empresas y productos: basado en las experiencias
de Ries trabajando con varias iniciativas de emprendimiento (startup), el método se
basa en que los ciclos de desarrollo de productos pueden reducirse en duración por
medio de ciclos continuos de experimentaciones, iteraciones y lanzamientos de
producto.
• En 2013 se publicaba la quinta edición de la guía PMBOK® del PMI.
 EL CICLO DE VIDA
DE LOS PROYECTOS

“Drive out fear (so that everyone may work effectively for the company)”

“Desechar el miedo, de manera que cada uno pueda trabajar con eficacia
para la compañía”

Principio número 8 de la Calidad Total de Deming

 ACTIVOS DE LOS PROCESOS
DE LA ORGANIZACIÓN
Procesos y procedimientos.
• Guías y criterios para adaptar el conjunto de procesos y procedimientos estándar de
la organización con el fin de satisfacer las necesidades específicas del proyecto.
• Estándares específicos de la organización, tales como políticas, ciclos de vida del
producto y del proyecto, políticas y procedimientos de calidad.
• Plantillas.
• Procedimientos de control de cambios.
• Procedimientos de control financiero.
• Procedimientos para la gestión de incidentes y defectos que definen los controles.
• Requisitos de comunicación de la organización.
• Procedimientos para asignar prioridad, aprobar y emitir autorizaciones de trabajo.
• Procedimientos de control de riesgos.
• Guías, instrucciones de trabajo, criterios para la evaluación de propuestas y criterios
estandarizados para la medición del desempeño.
• Guías o requisitos de cierre del proyecto.
 BASE DE CONOCIMIENTO
CORPORATIVA
• Bases de datos de conocimiento de la gestión de configuración, que
contienen las versiones y líneas base de todos los estándares, políticas
y procedimientos de la organización ejecutante.
• Bases de datos financieras con informaciones tales como horas de
trabajo, costes, presupuestos, y cualquier déficit presupuestario del
proyecto.
• Información histórica y bases de conocimiento de lecciones
aprendidas.
• Bases de datos de incidentes y defectos.
• Bases de datos para la medición de procesos, utilizadas para
recopilar y tener disponibles las medidas realizadas sobre procesos y
productos.
• Archivos de proyectos anteriores.
 ENFOQUES PARA LA
GESTIÓN DE PROYECTOS
Un proyecto se puede dividir en cualquier número de fases. Una fase
del proyecto no es más que un conjunto de actividades, relacionadas
de manera lógica, que culmina con la finalización de uno o más
entregables.
Aunque las prácticas comunes de la industria conduzcan con
frecuencia a utilizar una estructura preferida, los proyectos en el
ámbito de una misma industria, o incluso dentro de la misma
organización, pueden presentar variaciones significativas.
Algunas organizaciones establecen políticas de estandarización de
todos los proyectos, mientras que otras permiten que el Equipo de
Proyecto seleccione y adapte el enfoque más apropiado para su
proyecto individual: un Equipo de Proyecto puede dividir un proyecto
en dos fases, mientras que otro Equipo diferente puede optar por la
gestión de todo el trabajo en una sola fase.
CICLOS DE VIDA PREDICTIVOS
CICLOS DE VIDA ITERATIVOS
E INCREMENTALES
MODELO BÁSICO DE
CICLO DE VIDA ÁGIL
 MARCO DE PROCESOS PARA LA
GESTIÓN DE PROYECTOS DE
TECNOLOGÍAS DE LA INFORMACIÓN

“Institute leadership (the aim of supervision should be to help people,

machines and gadgets to do a better job. Supervision of management is in
need of overhaul, as well as supervision of production workers)”

“Implantar el liderazgo: El objetivo de la supervisión debería consistir en

ayudar a las personas y a las máquinas y aparatos para que hagan un
trabajo mejor. La supervisión de la dirección necesita una revisión, así como la
supervisión de los operarios”
Principio número 7 de la Calidad Total de Deming
 PROYECTOS DE TECNOLOGÍAS
DE LA INFORMACIÓN
• Impacto directo o indirecto en la globalidad de la
organización.
• Interdependencia con otros proyectos o servicios de TI.
• Riesgo continuado de obsolescencia tecnológica.
• Intensa participación del recurso humano de distintas áreas
de la empresa durante el desarrollo del proyecto.
También en este caso se utilizarán metodologías bien
definidas, aunque será frecuente el uso de herramientas
informáticas que faciliten su gestión de forma automatizada.
 TIPOS DE PROYECTOS

• Desarrollo de nuevas aplicaciones de software.

• Selección y adquisición de nuevos paquetes de software.
• Despliegue de una aplicación comercial.
• Mantenimiento de aplicaciones y sistemas.
• Implantación o actualización de plataformas de hardware.
• Despliegue de servicios de TI para unidades de negocio.
• Mejora de las comunicaciones y redes.
 TIPOS DE PROYECTOS
• Diseño o implantación de infraestructuras de alojamiento y operación
de los sistemas de procesamiento y comunicaciones.
• Externalización de servicios de TI (outsourcing).
• Consultoría de Arquitectura TI o, en general, de diseño de sistemas y
servicios.
• Auditorías de seguridad, de calidad, de sistemas o de cumplimiento
normativo.
• Adopción de nuevas arquitecturas y productos de gestión de la
información corporativa (Business Intelligence, Big Data,…).
• Reingeniería de sistemas o de servicios de TI.
• Otros.
 PROCESOS DEL CICLO DE
VIDA DEL SOFTWARE
• Consistencia y repetibilidad de los resultados a lo largo de los diferentes
proyectos de la organización: Las tareas definidas en un proceso son
consistentes a lo largo de los diversos proyectos independientemente de
quién las realice, ayudando a que los resultados sean predecibles y
repetibles.
• Mayor eficacia y eficiencia del personal: La organización puede comunicar
de forma mucho más efectiva los procesos a sus empleados y estos pueden
comprender de forma clara sus responsabilidades en las tareas que
ejecutan, así como los resultados y objetivos de las mismas.
• Mayor eficiencia organizacional: La organización puede diferenciar las
tareas rutinarias de las tareas creativas, permitiendo abordar las tareas
rutinarias de forma más precisa y eficiente. Esto a su vez incide en que se
pueda dedicar más tiempo a la realización de las tareas creativas.
• Simplificación de la gestión de los procesos: La definición de los procesos es
el primer paso en la gestión de los mismos. En los procesos definidos por una
organización se pueden establecer mediciones para controlar el
desempeño y definir mejoras.
 EJEMPLOS DE NORMAS DE
• La Guía del PMBOK®.
REFERENCIA
• La metodología PRINCE2®.
• La metodología MAGERIT de Análisis y Gestión de Riesgos de los Sistemas de
Información en la Administración Pública Española6.
• La norma estadounidense TechAmerica Standard “Configuration Management
Standard EIA-649-B”, de 20117, sobre el proceso de gestión de la configuración.
• La norma estadounidense “1042-1987 IEEE Guide to software configuration
management”8, relativa al proceso de gestión de la configuración del software.
• La metodología Proceso Unificado de Desarrollo (Unified Software Development
Process) refinada posteriormente por Rational en el Proceso Unificado de Rational
(Rational Unified Process, RUP)9, que proporciona un marco de procesos de
desarrollo que se puede adaptar en la implementación de los procesos específicos
del software definidos en ISO/IEC 12207.
• La norma ISO/IEC 14764:200610, que describe en mayor detalle el proceso de
mantenimiento del software definido en la ISO/IEC 12207.
• La metodología de pruebas TMap NEXT11, que define varios procesos relacionados
con el ciclo de vida de las pruebas del software: permite abordar varios de los
objetivos de los procesos de aseguramiento de la calidad, verificación y validación
del software de la norma ISO/IEC 12207.
CICLO DE GESTIÓN
DE PROCESOS
Nivel de Capacidad del Descripción
Capacid Proceso
ad
Nivel 0 Proceso El proceso no está implementado o no se cumplen sus objetivos.
incompleto
Nivel 1 Proceso Se cumplen los objetivos del proceso, como demuestra la
realizado obtención de los resultados (outcomes) del mismo. Sin embargo,
el proceso se realiza de manera informal.
Nivel 2 Proceso El proceso, además de realizado, es gestionado, es decir, se
gestionado planifica, se controla y se realizan ajustes durante su ejecución.
Nivel 3 Proceso El proceso, además de gestionado, se implementa de acuerdo a
establecido unas pautas definidas. De esta forma, existe un proceso definido de
forma estándar para toda la organización, el cual se puede
adaptar en cada realización concreta, siguiendo un método
establecido para ello.
Nivel 4 Proceso El proceso, además de establecido, opera dentro de unos límites
predecible bien conocidos.
Nivel 5 Proceso en El proceso, además de predecible, se mejora continuamente para
optimización satisfacer los objetivos de negocio de la organización.
 MODELOS Y METODOLOGÍAS
PARA LA GESTIÓN DE
PROYECTOS TI
“Remove barriers that rob the employees/managers of pride of workmanship”

“Eliminar las barreras que privan a la gente de su derecho a estar orgullosa

de su trabajo: Estas barreras se deben eliminar para dos grupos de personas.
Un grupo es el de dirección o personas con salario fijo. La barrera es la
calificación anual de su actuación, o calificación por méritos; el otro grupo es
el de los trabajadores por horas”
Principio número 12 de la Calidad Total de Deming
MODELO EN CASCADA
MODELO EVOLUTIVO
MODELO BASADO EN
COMPONENTES
Metodología tradicional
Más artefactos. El modelo es esencial,
mantenimiento basado en los modelos.
Más roles y más específicos.
Existe un contrato prefijado.
El cliente interactúa con el equipo de desarrollo
mediante reuniones.
Aplicables a proyectos de cualquier tamaño,
pero suelen ser especialmente efectivas/usadas
en proyectos grandes.
Se promueve que la arquitectura se defina
tempranamente en el proyecto.
Énfasis en la definición del proceso: roles,
actividades y artefactos.
Basadas en normas provenientes de estándares
seguidos por el entorno de desarrollo.
Se espera que no ocurran cambios de gran
impacto durante el desarrollo.
Metodología ágil
Pocos artefactos. El modelo es
prescindible, modelos desechables.
Pocos roles, más genéricos y flexibles.
No existe un contrato tradicional, debe
ser bastante flexible.
El cliente es parte del equipo de
desarrollo.
Orientada a proyectos pequeños, y en
el mismo lugar.
La arquitectura se va definiendo y
mejorando a lo largo del proyecto.
Énfasis en los aspectos humanos: el
individuo y el trabajo en equipo.
Basadas en heurísticas provenientes
de prácticas de producción de
código.
Se esperan cambios durante el
desarrollo del proyecto.