gerencia de proyectos & arquitectura de...

Jorge Arias ([email protected] / [email protected] )

Solutions Architect

Oracle Consulting Latin America Division (LAD)

IX Jornada de Gerencia de Proyectos de TI

Marzo 24 y 25 de 2011

Bogotá - Colombia

Gerente de Proyectos + Arquitecto

de Solución= Proyectos Orientados

al Éxito

mailto:[email protected]




Objetivos

• Presentar como la correcta articulación de los roles de gerente

de proyecto y arquitecto de solución ayudan a enfrentar la

complejidad inherente a los proyectos hoy en día, y orientar los

mismos hacia el éxito.

• Describir, a partir de experiencias en el campo, las principales

responsabilidades que debe asumir un rol de arquitectura, y

como estas complementan las realizadas por un gerente de

proyectos.

Agenda

• Contexto

• Arquitectura & Gerencia de Proyectos

• Dimensiones de un rol de arquitectura

• Conclusiones

“Experiencia es lo que tú consigues, cuando no

consigues lo que quieres” Randy Pausch, 2008 CMU (En su best seller “The

last lecture”)

“Simplicidad es una ilusión, es tan sólo

complejidad bien administrada” Anne Thomas- Burton Group

Motivación & Contexto

Proyecto = Experiencia + Simplicidad

1994

➔ Sólo el 16.2% de los proyectos son exitosos

➔ 31.1% de los proyectos son cancelados antes de terminarlos

➔ 52.7% de los proyectos terminados no cumplen con los requerimientos funcionales mínimos.

Tiempo Alcance

Recursos ( $$$, Gente)

Calidad

Usabilidad 2009

➔ Sólo el 32% de los proyectos son exitosos

➔ 24% de los proyectos son cancelados antes de terminarlos

➔ 44% de los proyectos terminados no cumplen con los requerimientos funcionales mínimos.

¿Por qué la mejora ?

• Orientación al negocio,

• Gerencia de proyectos,

• Evolución de frameworks de arquitectura


En dónde estamos… (Los tiempos cambian)

¿ La complejidad de los problemas a resolver será la

misma?

Fuente: http://www1.standishgroup.com/newsroom/chaos_2009.php

N-0: Macroprocesos

N-1: Grupos de procesos

N-2: Proceso de negocio

N-3: Actividades de negocio

N-4: Procedimientos/Tareas de negocio

N-5: Pasos/Requermientos de negocio

Motivación & ContextoAlcance de los proyectos de TI – Granularidad de los procesos

de negocio

X-Telco

7.0 Manage IT8.0 ManageFinancial

Resources

8.6 ProcessAP & Expense

Reimbursement

8.6.1 ExpenseReimbursement

8.6.1.1 Establish &Communicate

Expense Policies

8.6.1.2 ProcessReimbursements

& Advances

8.6.1.1 CompleteExpense Request

8.6.1.2 ReviewExpense Request

8.6.1.3 ApproveExpense Request

8.6.1.3 ApproveReimbursements

& Advances

8.6.1.4 VerifyExpenseRequest

8.6.1.4.2 ReviewChange Rate

8.6.1.4.1 VerifyExpense

Policy Compliance

8.6.1.5 TransferFunds

8.6.2 ProcessAccounts Payable

8.7 ManageTreasury

Operations

8.8 ManageInternal Controls

9.0 Acquire,Construct &

Manage Property

Level 0Major Business

Functions

Enterprise

Level 1ProcessGroups

Level 2Business Process

Level 3Business Activity

Level 4Business

Task

Level 5Business

Step

Motivación & ContextoAlcance de los proyectos de TI – Granularidad de los procesos

de negocio vs. Tipo de proyectos

(1) Desarrollo de a la medida

(2) Adoptar un ERP

(3)Proyecto de Integración

Gestión del proyecto

Motivación & ContextoAlcance de los proyectos de TI – Diferencias entre ingeniería y

Gestión

Tres DIREFERENTES tipos de proyectos de TI

•Desarrollo a la medida

•Adopción de un CRM

•Proyecto de integración

Metodología

Modelos de estimación

Arquitectura

Tecnología

Roles

Gestión del alcance

Gestión del riesgo

Gestión del tiempo

Gestión de recursos

Gestión de costos

Ingeniería del proyecto

Igual para los tres proyectos

Diferente y dependiente del tipo de proyecto

Motivación & ContextoAlcance de los proyectos de TI – Diferencias entre ingeniería y

Gestión

Tres DIREFERENTES tipos de proyectos de TI

•Adopción de un CRM (Telcos)

•Adopción de un CRM ( Banca)

•Adopción de un CRM (Retail)

Metodología (=)

Modelos de estimación (<>)

Tecnología (=)

Roles (<>)

Conocimiento de industria (<>)

Arquitectura (<>)

Gestión del alcance

Gestión del riesgo

Gestión del tiempo

Gestión de recursos

Gestión de costos

Ingeniería del producto

Gestión del producto

Igual para los tres proyectos

Diferente y dependiente del tipo de proyecto

Modelo host


Los proyectos de TI son

cada vez más complejos

2005

1998

1970

1980

1990Terminal

Host

-Presentación

-Negocio

- Datos

Cliente

Servidor

-Presentación

-Negocio

-Datos

Modelo Cliente/Servidor dos niveles

Cliente

Servidor

-Presentación-Negocio

-Datos

Modelo Cliente/Servidor modificado

Terminal

(Browser)

WebServer

DBServer

AppServer

Lógica

Presentación

Lógica Negocio

(componentes)

Datos

Multicapas

Problema de negocio

2009 Canales (Web2.0) Portal

BPM

ESB

Dashboard

Pesentación

Negocio

Datos

Modelo SOA/BPM

Proyecto de TI soportado en cada estilo de arquitectura

• Las arquitecturas han tenido que venir evolucionando como forma de

respuesta a las necesidades, cada vez más exigentes y diversas, del

negocio.

• Los estilos de arquitectura no son una moda, son una clara forma de

resolver y responder a la complejidad (Legacy, Client-Server, Multi-

capas, Servicios, etc.)


Los proyectos de TI son cada vez más complejos (2)

Ingeniería

Diferente

Gestión

Igual


Los proyectos de TI son cada vez más complejos (3)A

lca

nc

e e

mp

res

ari

al

Desarrollo a la medida

Implantación de un COTS (ERP, CRM, Facturador, etc.)

Implantación de procesos transversales (CRM Integración ERP/ Facturador)

Solución de negocio ( Proyectos tipo: desarrollo a la medida, implantación de

plataforma de TI, COTs)

Proyecto de implantación de herramientas de tecnología ( ESB, BPM, iAM, BI)

Heterogeneidad de habilidades requeridas

Sistema Financiero

( SAP)

Sistem Atención al cliente ( Siebel,

People Soft)

Sistema de facturación

Sistema de ordenes de

trabajoAprovisionamiento en linea planes de datos


Ejemplo: Habilitar una capacidad de negocio

Proyecto de adoptar un CRM

Proyecto desarrollo a la medida (Modificar el facturador)

Proyecto de integración (Implantar un Bus)


Resumen: La complejidad de los proyectos de TI es

cada ves mayor

Los principios de administración y gestión

del proyecto se mantienen entre proyectos de TI

Estilos de arquitectura

Metodologías diferentes

Roles & Skills

Motivadores de negocio

Adopción de un COTs (CRM, ERP)

Desarrollo a la medida

Diferentes industrias (Telco,

Banca, Retail, etc.)

Implantar plataformas

técnicas (Bus, iAM, BPM, Sistemas

operativos)

Motivación & ContextoResumen ¿El PM Puede asumir la gestión e ingeniería?

Solución = Producto

¿QUÉ?•Procesos de negocio

•Modelos de datos

•Aplicaciones

•Motivadores de negocio

•Tecnología

¿CÓMO?• Metodología

• Mapas de solución

• Arquitectura

• Equipo de trabajo

Gestión

Alcance

Riesgo

Tiempo

Recursos

Costes

Otros.

¿Gerente de proyectos?

PR

OY

EC

TO

¿ Si vamos hacia un mundo de especialización;

porque esperamos o motivamos escenarios para

que el PM le apueste a la generalización?

Vamos a ser más competitivos y eficientes en

nuestros proyectos cuando le apostamos a la

especialización ( Ingeniería y gestión

correctamente articulado)

Motivación & Contexto¿ Qué piensan y cómo se sienten los Gerentes de proyectos?

Proyectos complejos hoy en día: Costos, alcance, tiempo,

recursos, arquitectura, metodología, conocimiento de

industria etc.

Llegamos a situaciones de desespero en donde no

sabemos si gritar o correr

Agenda

• Contexto

• Arquitectura & Gerencia de proyectos


• Conclusiones

Arquitectura y Gerencia de ProyectosEstructura dimensional del problema y esencia cambiante del

mismo

Procesos de negocio

Modelo de información

Aplicaciones

Tecnología

Cultura y Gestión del Cambio

Gobernabilidad

Estrategia de Negocio

Iniciativa o Proyecto #1

Define

Define

Define

Iniciativa o Proyecto #2

Iniciativa o Proyecto

#N

Ciclos de reconovación más cortos

Proyectos cambiantes

15% - 20%


El PM necesita alguien que le da claridad en el QUE

y en el CÓMO del proyecto

Solución = Producto

¿QUÉ?•Motivadores de negocio

•Procesos de negocio

•Modelos de datos

•Aplicaciones

•Tecnología

¿CÓMO?• Metodología

• Mapas de solución

• Arquitectura

• Equipo de trabajo

Gestión

Alcance

Riesgo

Tiempo

Recursos

Costes

Otros.

Arquitecto

Gerente de proyectos

PR

OY

EC

TO

Conocimiento de industria

Arquitectura y Gerencia de ProyectosEn TI el PM si debe conocer de TI. No es tan fácil aislarse de

la ingeniería de la solución (Sería todo un riesgo)

Gestión de proyectos

Metodología


Arquitectura

Tecnología

Habilidades de comunicación

Arquitecto

Gerente Proyectos

Arquitectura y Gerencia de ProyectosGénesis y componentes de un proyecto

Problema de negocio

QUÉ CÓMO Implementación / Implantación COMO

Alcance

Tiempo Recursos

Comunicación Riesgos

Costos

Calidad

Adquisiciones

Contrato

Arquitectura y Gerencia de ProyectosArticulación de dos roles (Arquitectura + Gerencia de

Proyectos) (1)

Problema de negocio

QUÉ CÓMO Implementación / Implantación

COMO

Alcance

Tiempo Recursos


Costos

Calidad

Adquisiciones

Contrato

Ingeniería del producto / Solución

Gerencia del producto / solución

Arquitecto de solución

Gerente de Proyectos

Arquitectura y Gerencia de ProyectosArticulación de dos roles (Arquitectura + Gerencia de

Proyectos) (2)

Problema de negocio

QUÉ CÓMO Implementación / Implantación

COMO

Alcance

Tiempo Recursos


Costos

Calidad

Adquisiciones

Contrato

Ingeniería del producto / Solución

Gerencia del producto / solución

Enfoques & Habilidades

(Industria, metodologia, tecnologia, estilos, etc.)

Gerente de Proyectos

Arquitectura y Gerencia de ProyectosSolución basada en restricciones & Realidades

Alcance

Tiempo Recursos


Costos

Calidad

Adquisiciones

Contrato

Arquitecto


Regulaciones de industria Requerimientos no funcionales

Estandares

Herramientas

Tecnologías disponibles

Presupuesto

Cultura Organizacional Solución

Arquitectura y Gerencia de ProyectosGestión del Cambio

Alcance

Tiempo Recursos


Costos

Calidad

Adquisiciones

Contrato

Arquitecto


Regulaciones de industria Requerimientos no funcionales

Estandares

Herramientas

Tecnologías disponibles

Presupuesto

Cultura Organizacional

Cambio

Gerentes de proyectos & Arquitectos de solución:

Instrumentos para atacar complejidad

Escenario de cooperación #1: Proyecto de

conceptualización como enfoque de mitigación de

riesgos en proyectos de gran escala, alta

incertidumbre, presupuestos altos.

Discovery / Scoping Analisis

Especificación de

NegocioAnálisis Diseño

Construcción

Pruebas Roll-out

Arquitectura y Gerencia de ProyectosImportancia de los proyectos de conceptualización

Proyecto de conceptualización

Proyecto de implementación/implantación

Forma de contratación: Time & Materials

Enfoque arquitectónico: Entender el QUÉ vía un análisis de arquitectura empresarial

29

Arquitectura tecnológica Solución

Arquitectura e Implementación


El QUÉ no sólo se resuelve con tecnología

Arquitectura Empresarial

Arquitectura de Procesos de Negocio

Arquitectura de datos e información

Arquitectura de interfaces & Aplicaciones

Arquitectura tecnológica

Solución


El QUÉ requiere de un análisis multidimensional del

problema (1)

Problema de negocio a soportar sobre una

solución IT

Negocio

Datos & Información

Aplicaciones

Tecnología

AS-IS TO-BE

Modelos

de referencia

Buenas

prácticas &

Regulaciones

Motivadores de

Negocio y

Condiciones

de mercado

Estandares

actuales

Operación

diaria

Sistemas

Actuales

Arquitectura y Gerencia de ProyectosArquitectura Empresarial como nuevo enfoque de análisis (1)

Problema de negocio a soportar sobre una

solución IT

32

AS-IS TO-BE

Modelos

de referencia

Buenas

prácticas &

Regulaciones

Motivadores de

Negocio y

Condiciones

de mercado

Estandares

actuales

Operación

diariaSistemas

Actuales

GAP

ROADMAP

Este roadmap debe ser priorizado y concertado

entre los diferentes stakeholders


33

1. Levantar AS-IS

2. Determinar TO-BE

3. Identificar brechas

4. Priorizar

5. Elaborar roadmap

Arquitectura

de Aplicaciones

…

MOTIVADORES

DE NEGOCIO …

1

1. Levantar AS-IS

2. Determinar TO-BE


4. Priorizar

5. Elaborar roadmap

Arquitectura

de negocio …

2

1. Levantar AS-IS

2. Determinar TO-BE


4. Priorizar

5. Elaborar roadmap

Arquitectura

de datos e Información

…

3

4

1. Levantar AS-IS

2. Determinar TO-BE


4. Priorizar

5. Elaborar roadmap

Arquitectura

Tecnología

…

5

6


Discovery / Scoping Analisis

Especificación de

NegocioAnálisis Diseño

Construcción

Pruebas Roll-out

Arquitectura y Gerencia de ProyectosImportancia de los proyectos de conceptualización

Proyecto de conceptualización

Proyecto de implementación/implantación

Forma de contratación: Fixed-Price

Enfoque arquitectónico: Entender el COMO vía un análisis de arquitectura de solución

¿COMO?¿QUE?

Problema de negocio

50,000fts

Arquitecto Empresarial

1,000fts

200fts

Arquitecto de Solución

Analista de requerimientos,

Developer / Programer 0fts

100fts

Procesos de negocio

Entidades de negocio

Modelos de da<tos

Mapa de aplicaciones

Mapa de integración

Mapa tecnológico

Funcionalidades de negocio

Definición de Componentes lógicos

Modelos de persistencia

Esquemas de Integración basada en servicios vs. RMI vs. CORBA

Enfoques de replicación y alta disponibilidad

Caso de uso

Diagrama de clases

Diagrama de secuencia

Modelo detallado de datos

Prototipo de GUI

Análisis AS-IS vs. TO-BE de procesos

Asignación de dueños de datos

Asignación de dueños de funcionalidades

Selección del estilo de arquitectura (SOA, N-tier, Client/server, etc.

Patrones de arquitectura.

Composiciones basadas en BPEL y SCA

Estructura de componentes requeridos (Lógicos & Infraestructura)

Estilos de mensajería

Balanceo de carga RR y disponibilidad basada en virtualización

Patrones de diseño

Clases en Java

Componentes JEE

Modelo de datos en Oracle RDBMS

Mensajería basada en JMS

Idioms

Arquitectura y Gerencia de ProyectosAbstracción de la solución

Solución

Gerencia

de

proyectos

Iniciativa o Proyecto Corporativo

Arquitectura Empresarial

¿QUÉ?Arquitectura de Solución

¿CÓMO?

Detalle de

la solución

Arquitectura y Gerencia de ProyectosArquitectura Empresarial & Arquitectura de Solución



Escenario de cooperación #2: Empresa proveedora

de servicios (Software House, Consultora, etc.)

Arquitectura y Gerencia de ProyectosCiclo de vida..

Generación de demanda Venta Bid-Transition Delivery

Dimensión Preventa Dimensión Delivery


Generación de demanda Venta Transición Venta-

EntregaEntrega

- Speaker en eventos: Compartir experiencias en proyectos x industria, tendencias

- Participar en comunidades / Comités de arquitectura de la industria

- Oferta de valor de la organización para hacer proyectos de TI

- Escribir artículos de casos de estudio (análisis post-morterm: Lecciones aprendidas)


Generación de demanda Venta Transición venta-

entregaEntrega

- Conceptualizar y abstraer las problemáticas de negocio que tiene el cliente; y las cuales motivan contratar un proyecto de TI.

- Visionar una arquitectura conceptual de solución que responda a las problemas de negocio del cliente

- Ayudar a estructurar un proyecto para implantar la solución conceptualizada (roles, tiempos, esfuerzos, dependencias funcionales y técnicas)

- Planear y participar en la ejecución de un proyecto de conceptualización.

- Explicar, defender y vender la solución frente al cliente


Generación de demanda Venta Transición venta-

entrDelivery

- Explicar al PM asignado al proyecto el alcance funcional y técnico de la solución vendida al cliente.

- Elaborar un “WBS template” de cómo ejecutar el proyecto en terminos de: Fases metodológicas, tareas de alto nivel x fase, esfuerzo y dependencias.

- Explicar y transferir al PM los riesgos que se asumieron durante la venta para ganar el negocio.

- Ayudar al PM al elaborar el ETC (Estimated to be completed) para que este pueda compararlo contra el BID (Valor del proyecto (Costo + Margen estimado) (¿ Siempre le cuadra que el ETC inicial es igual al BID?)


Generación de demanda Venta Bid-Transition Entrega

- Participar activamente en la fases de conceptualización (inception) y elaboración

- Elaborar la arquitectura de solución del proyecto (Lógica y Física)

- Generar lineamientos, principios diseños, y practicas para el equipo de diseño e implementación

- En la fase construcción realizar actividades de QA (1 vez al mes) que permitan validar que la solución esta siendo construida acorde a la arquitectura planteada (Evitar desviaciones)

- A lo largo del proyecto: servir de ente consultivo respecto a temas de ingeniería del PM y manejo de expectativas frente al cliente.



Escenario de cooperación #2: Empresa

Compradora de tecnología

Agenda

• Contexto



• Conclusiones

Experiencia

Habilidades de comunicación

Tecnología

Metodología


Capacidad Abstracción

Dimensiones de un rol de arquitecturaEjes estructurales del rol

Arquitecto

Dimensiones de un rol de arquitecturaDesarrollador vs. Especialista técnico/producto vs. Arquitecto

Solución

Agenda

• Contexto



• Conclusiones

• Gerencia de proyectos y Arquitectura deben ir de la mano para

enfrentar la complejidad inherente de los proyectos de hoy en día.

• La naturaleza de los proyectos está obligando a que Arquitectura y

Gerencia de proyectos sean roles ejecutados por personas y/o

grupos diferentes (Demasiadas cosas para ser ejecutadas por la

misma persona, no obstante tenga en cuenta el tamaño del proyecto)

• No se deje engañar de las vistas a alto nivel (50,000fts, 30,000fts),

donde todo es fácil, simple, etc. (Recuerde el que nada sabe nada

teme)

• El rol de arquitectura al interior de los proyectos no es una moda, es

una respuesta a la complejidad de los proyectos, y está convirtiéndose

en el mejor seguro de los gerentes de proyectos.

Arquitectura y Gerencia de ProyectosResumen…

Preguntas & Respuestas

gerencia de proyectos & arquitectura de...

Documents