Seikko Grupo Business

CURSO DE ADMINISTRACION
PROYECTOS

Seikko Grupo Business

Seikko Grupo Business

La Empresa
Seikko - Grupo Business es una consultora seria y de reconocido prestigio
dedicada a la asesora, consultora y gestora financiera y administrativa
empresarial y gubernamental. Tenemos a disposicin de nuestros clientes,
profesionales con experiencia y un excelente currculum que estn en constante
perfeccionamiento para poder brindar el mejor servicio, profesional y el trato
excelente que nuestros clientes merecen.
Con una visin sustentada en escuchar a nuestros clientes, acercamos a cada
cliente soluciones pensadas exclusivamente para sus necesidades Profesionales.
Expertos en Cushing empresarial e institucional, con ms de 10 aos de
experiencia en los sectores pblico, privado y social.

Seikko Grupo Business

Administracin de Proyectos

La administracin de proyectos es la disciplina de gestionar proyectos exitosamente, la

cual puede y debe aplicarse durante el ciclo de vida de cualquier proyecto (Dixon,
2000).
A lo largo de esta seccin se abordaran temas relacionados con la administracin de
proyectos, sus etapas, y otras consideraciones para comprender a grandes rasgos el
objetivo de esta disciplina.
Definicin de Administracin de Proyectos
Existen varias definiciones de la Administracin de proyectos, a continuacin se
muestran algunas:
De acuerdo con una enciclopedia en lnea, la administracin de proyectos es la
disciplina que se encarga de definir y alcanzar objetivos optimizando el uso de
recursos: tiempo, dinero, la gente, espacio, etc. (Project management., 2005).
Otra definicin nos dice que: la administracin de proyectos es la forma de planear,
organizar, dirigir y controlar una serie de actividades realizadas por un grupo de
personas que tienen un objetivo especifico; el cual puede ser (crear, disear, elaborar,
mejorar, analizar, etc.) un problema o cosa (Rodrguez, 2002).

Distincin entre una Metodologa de Administracin de Proyectos y una

Metodologa de Desarrollo de Software
Es importante establecer una distincin entre una metodologa de Administracin de
proyectos y una metodologa de desarrollo de software. La importancia de distinguir
entre ambos conceptos radica en que una organizacin debe contar con una
metodologa de administracin de proyectos consistente a cualquiera que sea la
naturaleza del proyecto que se desarrolla. Las diferencias entre ambos conceptos se
enlistan en la Tabla 1 (Neville, 2005).

Seikko Grupo Business

Metodologa de Administracin de
Proyectos

Metodologa de Desarrollo de
Aplicaciones

Dice que los proyectos deben ser divididos en Establece cules son las fases y qu
fases y antes de iniciar con cada una de ellas actividades involucra
debe existir un plan

Define roles y responsabilidades

Define cules son los roles y

responsabilidades que corresponden a
cada fase

Dice que un pre supuesto debe ser definido y Define qu medidas deben emplearse
administrado.
para contabilizar el desarrollo en la
organizacin.

El proceso de administracin de proyectos recibe como entradas o es afectado por

(Dixon, 2000):

Necesidades y requerimientos del proyecto a desarrollar (alcance).

Limites establecidos en tiempo, costo, calidad, desempeo requerido, aspectos

legales, etc.

Mecanismos para lograrlo entre los que estn: personas, tcnicas, herr
amientas, equipo y organizacin.

En base al desempeo de dicha Administracin se entregan

productos o servicios como salida, tal como se observa en la Figura
1.

Seikko Grupo Business

Figura 1 . Proceso de Administracin de Proyectos. Fuente: (Dixon, 2000)

Fases de la administracin de Proyectos

En la perspectiva tradicional, es posible distinguir 5 componentes de un proyecto (4
etapas ms el control) en el desarrollo de un proyecto (Project management. 2005):

1.- Iniciacin de proyecto

2.- Planificacin de proyecto
3.- Produccin de proyecto o
ejecucin

Seikko Grupo Business

4.- Supervisin y control del Proyecto

5.- Finalizacin de proyecto o cierre

No todos los proyectos visitarn cada etapa ya que los proyectos pueden ser
terminados antes de que alcancen la finalizacin. Algunos proyectos probablemente no
tienen la planificacin y/o el control. Y algunos proyectos pasarn por pasos 2, 3 y 4
varias veces (Project management. 2005).
Fases del desarrollo de Software
Por otra parte, una de varias metodologas disponibles para el desarr ollo de sistemas
se compone por las siguientes fases (Rodrguez, 2002):

Investigacin Preliminar

Diseo del Sistema

Desarrollo de Sistemas

Pruebas del Sistema

Implantacin y evaluacin

Muchas metodologas varan en las fases que involucran y pueden realizar procesos de
retroalimentacin o iterativos hasta lograr tener un producto de
software terminado. Sea cual sea la metodologa, finalmente se
busca producir una aplicacin lista para su uso.

El
proceso de administracin de proyectos recibe como entradas o
es afectado por (Dixon, 2000):

Necesidades y requerimientos del proyecto a desarrollar (alcance).

Limites establecidos en tiempo, costo, calidad, desempeo requerido, aspectos

legales, etc.

Mecanismos para lograrlo entre los que estn: personas, tcnicas, herr
amientas, equipo y organizacin.

En base al desempeo de dicha Administracin se entregan productos o servicios como

salida, tal como se observa en la Figura 1.

Seikko Grupo Business

Figura 1 . Proceso de Administracin de Proyectos. Fuente: (Dixon, 2000)

Fases de la administracin de Proyectos

En la perspectiva tradicional, es posible distinguir 5 componentes de un proyecto (4
etapas ms el control) en el desarrollo de un proyecto (Project management. 2005):

1.- Iniciacin de proyecto

2.- Planificacin de proyecto
3.- Produccin de proyecto o
ejecucin
4.- Supervisin y control del Proyecto

Seikko Grupo Business

5.- Finalizacin de proyecto o cierre

No todos los proyectos visitarn cada etapa ya que los proyectos pueden ser
terminados antes de que alcancen la finalizacin. Algunos proyectos probablemente no
tienen la planificacin y/o el control. Y algunos proyectos pasarn por pasos 2, 3 y 4
varias veces (Project management. 2005).

xito y fracaso en proyectos de desarrollo de software

Sin considerar el tamao del proyecto, su alcance o duracin existen 5 mximas de
satisfaccin en su desarrollo (Boyd, 2001):

Entregar el producto que el cliente desea o necesita

Entregar la calidad de manera acorde con el precio

Entregar el producto en el espacio de tiempo que el cliente desea o necesita

Entregar el nivel de retroalimentacin que el cliente desea, y

Contar con un sistema de resolucin de conflictos justo para el cliente y el

equipo de desarrollo

Los que se consideran como pa sos bsicos esenciales para lograr una administracin
eficiente de proyectos se enumeran a continuacin (Toledo, 2002):
Por otro lado los aspectos crticos que contribuyen al fracaso de proyectos de
tecnologas de informacin incluyen (Brock, Hendricks, Linnell, & Smith, 2003) :

1.- Nunca iniciar sin un objetivo bien definido

2.- Fragmentar el proyecto
3.- Invertir tiempo en la planeacin
4.- Involu crar al equipo de trabajo en la planeacin y el
control
5.- Fomentar la cohesin del equipo de trabajo
6.- Prevenir problemas

Seikko Grupo Business

7.- Antes de ejecutar, establecer lneas de Base.

8.- Mantener claro el objetivo principal del proyecto.
9.- Establecer un proceso para monitorear y controlar
10.- Atender los puntos crticos primordialmente.
11.- Tomarse el tiempo necesario para cerrar el proyecto.
12.- Utilizar una metodologa para todos los proyectos.

Falta de visin clara y establecimiento adecuado de requerimientos

Expectativas irreales

Falta de descomposicin del proyecto

Polticas inadecuadas de seleccin de personal y conflictos en el equipo de

desarrollo.

Falta de involucramiento y enfoque hacia el cliente

Falta de enfoque estratgico y apoyo administrativo

Tanto los pasos bsicos para realizar una administracin proyecto como los aspectos
crticos que provocan fracasos en este proceso de desarrollo deben de ser
contemplados y corregidos, de acuerdo a la forma de trabajar de la empresa. De esta
manera se busca mejorar el proceso de desarrollo de los proyectos de software y
tomar en cuenta aquellas fallas comunes.

Seikko Grupo Business

PROCESOS CLAVES EN LA
ADMINISTRACION DE PROYECTOS

1 - Seguir un proceso de iniciacin estructurado: realizar un estudio de factibilidad

financiero, tecnolgico, de recursos, impactos, estratgico y de negocio del proyecto, para
prevenir inconvenientes, priorizarlo y obtener el soporte y justificacin de negocio
necesario para poder implementarlo. Durante la fase de inicio o arranque, una correcta
valoracin de riesgos, asunciones, obstculos y restricciones deben ser convenientemente
evaluados y el factor crtico es realizar un adecuado proceso de valoracin de
requerimientos (RM) para clarificar objetivos, necesidades y alinear las expectativas. En
muchos casos los procesos de RM pueden automatizarse pero siempre es conveniente
mantener sesiones y reuniones con los stakeholders para aclarar los puntos grises. Todas las
metodologas de administracin de proyectos recalcan la importancia de una fuerte relacin
con los stakeholders y su proceso de anlisis, dado que con ellos podremos lograr ms
fcilmente el xito y romper diversas barreras en los proyectos. Un error frecuente es que
muchos proyectos pueden tener un gran nmero de stakeholders y el team slo dialoga con
aquel ms sociable y entusiasta sin evaluar las expectativas de los otros que directa o
indirectamente estn involucrados y son precisamente los que pueden ponernos los palos en

la rueda. Un factor comn para el xito de los proyecto es poseer la

habilidad de negociar y manejar las expectativas y necesidades de los
stakeholders afectados por el proyecto. La relacin con el sponsor y los
stakeholders es vital y la clave es establecer una buena relacin lo que
implica ms que identificar y manejar sus expectativas, manejar una
conexin emocional con la gente. El PM debe focalizarse en mejorar sus habilidades

Seikko Grupo Business

interpersonales, y asegurarse de que todos los stakeholders estn a bordo del proyecto
manteniendo fluida comunicacin con ellos. El anlisis de los stakeholders debera permitir
al PM no slo identificarlos sino categorizarlos bajo distintos aspectos: relacin y actitud
hacia el proyecto, estn a favor o en contra del proyecto, cul es su poder e influencia,
existen conflictos entre ellos, etc.
2 - Planificacin del Proyecto: de acuerdo a la industria donde se realice el proyecto, la
planificacin podr tomar diferentes matices. Los proyectos para el desarrollo de software
son bastante particulares, tan es as, que surgieron metodologas propias para los mismos
(Agil Development) diferentes a las tradicionales como el PMBOK. Algunos aspectos
de las metodologas giles pueden ser utilizados en cualquier otro proyecto. Actualmente
est de moda hablar tambin de Lean Six Sigma Project Management, otra aproximacin a
la gestin efectiva de proyectos. Independientemente de que se utilice una metodologa
tradicional, gil o lean; una buena planificacin siempre es necesaria. En la metodologa
tradicional la planificacin es exhaustiva y completa, en los ciclos ms acelerados y
livianos (gil o lean) la planificacin se concentra en delimitar los bordes del proyecto para
crear una lista priorizada de entregables que sern liberados en fases de tipo iterativa.
Planes comprensivos, realistas y bien comunicados son imprescindibles en todos los
proyectos, an con cortos ciclos de vida. Involucrar no slo al team sino a los stakeholders
en el desarrollo de los planes, discutir acerca de todos los objetivos y entregables del
proyecto y explicar claramente los riesgos involucrados son tambin factores esenciales.
Como corolario final el consejo es no embarcarse en planificaciones extensas, construir
planes a corto plazo y detallados (elaboracin progresiva segn el mismo PMBOK), e ir
elaborando los requerimientos sobre la marcha en una aproximacin de tipo iterativo.
3 - Utilizar auditoras: para evaluar la salud del proyecto, deberan realizarse auditoras y
reuniones de quality assurance en forma frecuente para chequear no slo los entregables
sino el estado y progreso del proyecto. Medir el progreso real versus el costo y tiempo
estimado es muy importante, al igual que realizar mediciones de calidad respecto del
cumplimiento de los requerimientos y el alcance de los entregables. No podemos controlar
y mucho menos mejorar si no tenemos mtricas. Debemos desarrollar criterios estndar de
medicin tanto de calidad como de productividad y eficiencia, para saber no slo dnde
estamos sino qu y cmo debemos mejorar. El PM debe desarrollar todas las actividades y
procesos definidos dentro del grupo de Monitoreo y Control del Proyecto que involucra el

control del progreso del mismo (tiempo y tareas), el control del alcance
(cambios), control del rendimiento (performance), control de los costos
(mtodo del valor ganado) y el control de calidad. De dichos controles
surgirn reportes y medidas correctivas o preventivas.

Seikko Grupo Business

Las auditoras tambin pueden ser efectuadas por personal externo al proyecto, y se
denominan peer reviews, realizadas por colegas o el departamento PMO o de
Aseguramiento de Calidad. El alcance de la misma debera ser similar al comentado ms
arriba. Toda auditora consta de las siguientes etapas:

Planificacin: Eleccin del tipo de auditoras a realizar (costos, performance,

calidad, etc.), determinar los procedimientos a utilizar, eleccin del personal,
fijacin de su periodicidad (mensual, anual, espordica, etc.).

Realizacin de auditoras segn procedimiento y plan definidos: Es conveniente

desde el punto de vista prctico que la realizacin de auditoras sea sistemtica, y el
propio director o responsable del rea a auditar transmita a sus subordinados
afectados las fechas concretas en las que estas auditoras sistemticas van a
realizarse para que presten su mayor colaboracin. Los documentos que recaben los
resultados de las auditoras, es decir, respuestas, comprobaciones, resultados de
medidas y ensayos, etc., han de estar consensuados entre auditor y auditado, de tal
forma que recojan la conformidad de ambos, evitndose discusiones intiles. Se
trata de auditar la efectividad de la gestin del proyecto, tanto a travs del grado de
cumplimiento de los procesos, como a travs de la calidad del producto obtenido.

Evaluacin de los resultados de la auditora: Toda auditora ha de realizarse para

obtener una nota final que sirva, aunque slo sea comparativamente, para medir la
evolucin y progreso del proyecto. Lo que se pretende es la obtencin de una
valoracin totalmente objetiva por lo que el sistema de valoracin ha de ser
consensuado, y adems, experimentado durante cierto tiempo, para poder fijar las
seales de alerta, ndices de ponderacin, etc.

Redaccin de un informe y propuesta de medidas correctivas de ser necesario,

con expresin de su grado de urgencia: Una vez valorada la auditora y antes de
la redaccin del informe final y propuesta de las medidas correctoras, es
conveniente la reunin con el PM afectado por la auditora para que sea el primer

Seikko Grupo Business

informado y pueda incluso colaborar en la propuesta de medidas correctoras as como la
decisin sobre la urgencia de las mismas, pues es conveniente que tanto el informe de la
auditora como la propuesta de medidas correctoras, lo asuma como algo propio, entre
otras cosas porque a veces, podr ejercer ms presin sobre la Gerencia que el propio
auditor, sobre todo si alguna de las medidas propuestas corresponden o requieren
inversiones.
4 - Utilizacin de recursos humanos: la correcta utilizacin de las tcnicas blandas y el
uso adecuado de las habilidades interpersonales son factores crticos en el manejo de todos
los proyectos. Un tema controversial que suele traernos dolores de cabeza se refiere a las
horas que cargan los recursos al proyecto: deben ser las reales o tericas?. En las
organizaciones en las que trabaj, como ocurre con muchas consultoras o empresas de
servicios, al cliente se le cobra de acuerdo al proyecto un precio fijo o time & material
(por hora de consultora). En ambos casos se toma para la formacin del precio el cost
rate de los recursos que trabajarn en el proyecto, independientemente de que el recurso
pertenezca o no a la organizacin ejecutante. Si pertenece a la organizacin y trabaja ms
de 40 horas a la semana, su salario ser siempre el mismo, pero a los efectos de cobro al
cliente en el caso de time & material podramos cobrar las horas overtime, algo que, en la
prctica slo se le paga al recurso si es externo a la organizacin. En los casos de precio
fijo, durante la planificacin normalmente calculamos en la herramienta de scheduling 40
horas de trabajo semanal. Si observamos que existen recursos con sobre alocacin (ms de
8 horas por semana) la tcnica ms comn a utilizar sera el resource-leveling algo que
generalmente terminar por enviarnos el final del proyecto al lado oscuro de la luna. En la
prctica normalmente no se hace nada dado que el recurso si es parte de la plantilla de la
organizacin, trabajar esas horas extras que por lo general y debido a su rango no son
pagadas en la prctica dado que recibe su sueldo mensual fijo. El problema se presenta
cuando existen sistemas de control de costos y productividad que no toma en cuenta esta
realidad (dado que se maneja con planillas separadas). En estos casos es frecuente que se le

obligue al recurso a cargar las horas que realmente trabaja en el proyecto

en algn sistema para su registro. De ser as, estaremos en un aprieto
desde el punto de vista de costos, dado que las horas cargadas y costeadas
superarn lo que estaramos facturando. La nica solucin en este caso
ser que no cargue sus horas extras, bajando su nivel de billability, algo
que no slo puede perjudicar al recurso sino tambin al mismo gerente (problemas de
utilizacin y productividad). Otro tema importante es la no disponibilidad de los recursos
claves (algo frecuente en los proyectos de alta tecnologa). La demanda puede ser superior
a la oferta y los planes suelen subestimar el tiempo requerido para adquirir estos recursos,
lo mismo que el tiempo necesario para organizar el grupo (team building).

Seikko Grupo Business

5 - Estimacin en los Proyectos: las estimaciones de costos y tiempos en un proyecto
constituyen la parte ms difcil en la planificacin, y es ms un arte que una ciencia. Como
consultor tuve que realizar una revisin a un proyecto que estaba con un sobrecosto muy
elevado y queran un anlisis de la causa de la variacin del mismo. Mi primera pregunta
fue cul era el mtodo que utilizaban para las estimaciones, la respuesta clsica fue el
proyecto tiene que estar listo para Octubre y se vendi en este precio considerando una
determinada carga de recursos. Mi segunda pregunta fue si la base de estimacin es una
ficcin, como quiere que la varianza en el costo tenga algn significado?.
Lamentablemente muchas organizaciones venden sus proyectos de acuerdo a lo establecido
por Ventas y no tienen tiempo de realizar una estimacin bottom-up o utilizar buenas
tcnicas de mtodos cuantitativos de administracin de proyectos para al menos estimar las
variaciones e incertidumbres con los buffers de contingencias necesarios. Cuanto ms
largos en recursos, tiempo, costos o complejidad son los proyectos mucho ms complicada
resultar la realizacin de las estimaciones. El Standish Group a travs de sus estudios
empricos nos arroja estos resultados de xito/fracaso de proyectos en su relacin con su
tamao y duracin.

Tamao del proyecto

Personas

Tiempo (meses)

Porcentaje de xito

Debajo de $750K

55%

$750K-$1.5M

12

33%

$1.5M-$3M

25

12

25%

$3M-$6M

40

18

15%

$6M-$10M

+250

+24

8%

>$10M

+500

+36

0%

Esto nos demuestra una vez ms que los mega-proyectos pasaron de moda y que el
desarrollo iterativo es el mejor mtodo para mitigar riesgos y una estrategia buena para
estimar mejor el alcance, costo y tiempo de los entregables a distribur en el proyecto.

Seikko Grupo Business

6 - Practicar un estricto control de cambios: independientemente del tamao del

proyecto y para evitar el Scope Creep se deber ser muy riguroso en lo que respecta al
control y seguimiento de los cambios al proyecto, utilizar herramientas automticas de RM
(Requirement Management) y CM (Configuration Management). Tener muy claro el
procedimiento para solicitar los cambios, el tipo de formulario, cmo debe ser completado
y el mtodo para aprobacin respectivo. Si el Gerente de Proyecto no ha definido bien el
alcance inicial del proyecto, ser tremendamente difcil administrar el mismo. El propsito
de la administracin de cambios es proteger la viabilidad de la definicin del proyecto ya
definida y aprobada. Cuando se solicita formalmente un cambio implica que dicho cambio
est fuera del alcance acordado en la definicin del Proyecto o de los requerimientos o
solicitudes detallados durante el anlisis. Si dicho alcance es confuso, poco claro, o deja
lugar a interpretaciones, entonces el cliente dir que el cambio est dentro del alcance, y el
Gerente de Proyecto encontrar difcil apegarse a un proceso formal de Gestin de Alcance.
En algunos proyectos es posible anticipar todas las solicitudes y requerimientos durante el
proceso de anlisis. No obstante lo cual, siempre podr existir la posibilidad y la necesidad
de incorporar cambios durante el ciclo de vida. Estos cambios pueden ser muy necesarios
para la solucin, y pueden existir razones poderosas de negocio por las que deberan
incorporarse. El Gerente de Proyecto y el equipo de trabajo, deben reconocer el momento
en que los cambios son requeridos y debern seguir un proceso predefinido de gestin del
alcance. Este proceso, eventualmente, proporcionar informacin para que el sponsor tome
las decisiones pertinentes y tambin le permitir decidir si la modificacin deber aprobarse
en base al valor e impacto en el proyecto en trminos de costo y tiempo. Debe ser claro

para todas las partes que cumplir estos nuevos requerimientos con los
mismos recursos de la definicin anterior, es prcticamente imposible.
7 - Buffers: incertidumbre, probabilidades: son temas que hacen a la
gestin cuantitativa de los proyectos. Primero y fundamental es necesario
no mezclar (al menos sin identificar claramente) las contingencias que nos
tomamos en las estimaciones con la duracin puesta a cada tarea. Esta contingencia debe
ser claramente identificada y manejada para evitar el efecto de la famosa Ley de
Parkinson. El mtodo de la Cadena Crtica coloca todas estas contingencias en un buffer
compartido para todo el proyecto de uso exclusivo del PM. De no utilizar este mtodo el
PMBOK nos aconseja utilizar contingencias o buffers por las incertidumbres en las
estimaciones utilizando CPM/PERT, MonteCarlo, Varianza de la media, o simplemente un
porcentaje del total de costo o tiempo adicional. El clculo del tamao del buffer debe tener
en cuenta muchos factores. Hablar de incertidumbre en riesgos o en las estimaciones no es
exactamente lo mismo que hablar de cul sera la probabilidad de ocurrencia. En forma
simple, al arrojar una moneda existe una incertidumbre respecto de si saldr cara o ceca.
Pero no hay incertidumbre respecto de las probabilidades de que salga cara dado que ambas
tienen un 50%. Si la probabilidad de un

Seikko Grupo Business

evento se acerca ms al 100% estaremos mucho ms tranquilos porque reducimos su

incertidumbre, pero inevitablemente aumentaremos su rango. Por ejemplo, si tenemos una
pieza mecnica que a travs de mediciones hechas durante 5 aos sabemos que puede
causar daos humanos en un impacto con rango del 35% al 45% (10%) y esto no es
aceptable, lo que ocurrir es que se realizarn tareas de ingeniera para mejorar dicha pieza
y reducir ese impacto negativo. Supongamos que logramos armarla de otra forma y que
ahora las probabilidades de que ocurra algo malo son del rango entre 5% y 25% (20%).
Hemos reducido significativamente la probabilidad de un accidente pero como no hay
historia pasada el rango de la incertidumbre es ms alto (del 10 al 20%).
8 - Subcontratar desarrollos externos (Outsourcing): muchas veces he trabajado
como prime contractor en proyectos en donde tenamos muchos proveedores
involucrados (en algunos casos, su desarrollo era ms importante que el nuestro). En este
aspecto son vlidas todas las recomendaciones del PMBOK sobre adquisiciones, adems
de tener en cuenta todas las modalidades contractuales y de mantener el pari passu
(mismas condiciones de obligaciones y responsabilidades contractuales) de las clusulas del
cliente con nuestros proveedores. En este caso me referir a un tema muy corriente en el
ambiente de IT que es la exigencia de ciertos niveles de calidad (CMMI) que se suele
requerir cuando se contrata o se hace un outsourcing. La mayora de las empresas hoy en
da pregonan ser certificadas en CMMI. Esto es imposible dado que CMMI no es una

certificacin, el SEI no certifica organizaciones como el ISO o el ITSMF,

sino que autoriza a personas denominadas lead appraisers a conducir
auditoras para determinar el grado de madurez de la organizacin
respecto del modelo. El SEI no confirma la certeza del nivel de madurez
reportado, sino que su foco es ms bien la calidad continua de la
organizacin, que identifique en qu nivel se encuentra y que realice todos los esfuerzos
necesarios para mejorar su calidad y hacer sus procesos repetibles.
Datos de desempeo
India Japn

Estados
Unidos

Europa y
otros

Total

Nmero de proyectos

24

27

31

22

104

Programador LOC/MO

209

469

270

436

374

Mediana de ndice por

defecto/KLOC

.263 .020

.400

.225

.150

Seikko Grupo Business

El grfico mostrado ms arriba es un informe del IEEE Software que documenta un estudio
sobre 104 proyectos de software en el mundo. India es el pas que proclama tener la
mayora de sus empresas con Nivel 5 de CMMI y sin embargo est en el tercer lugar en
cuanto a programas con errores (el informe incluye empresas como Motorola India,
Infosys, Tata Consulting), algo como para tener en cuenta no?. No estoy desmereciendo la
evaluacin del modelo de madurez sino que debera preguntarse mucho acerca de cmo se
obtuvo y otras cuestiones de la empresa a contratar tales como:

Cundo fue publicado su ltimo assessment? (dura 2 aos)

Copia de la documentacin donde figura qu reas son las ms fuertes y cules con
las ms dbiles?.

Quin desarroll el lead assessment?

Cules son sus planes de mejora continua?

Con qu otros clientes trabaja?

Otra caracterstica asociada a la inmadurez de nuestro mercado es el error

de escuchar a un gerente decir: esta tarea ya no representa un problema
porque la hemos subcontratado. Esto es falso, fundamentalmente porque
la inestabilidad de nuestro mercado hace que sea muy difcil desarrollar
relaciones cliente proveedores que perduren en el tiempo. Por otro lado,
esta inestabilidad y lo pequeo del mercado generan el problema que los proveedores en
gran medida sean Pymes, y stas permanentemente deben de tener una muy agresiva actitud
de venta, sobre todo si son proveedores que dependen de la aparicin de proyectos en el
mercado para tener trabajo y resulta muy difcil su evaluacin porque no hay una manera
simple de saber el estado en que se encuentra dicho proveedor. Es posible analizar los
contratos que tiene en ejecucin, pero no es posible analizar los contratos que estn a la
firma, y muchas veces la concrecin de uno, genera mejores condiciones en las Pymes
para enfrentar las negociaciones con los otros contratos, y se produce una cascada de
contratos que se firman, una cantidad de compromisos simultneos que este proveedor tiene
que cumplir, y como generalmente no cuenta con reservas de recursos humanos ni con una
planificacin previa tiene como resultados crisis de recursos y falta de cumplimiento en
todos los contratos. En el caso a su vez que el contratista sub-contrate el servicio en otra
organizacin se le suma a la inestabilidad propia del contratista, que tiene sus crisis
internas, las que potencian a la de los subcontratistas. Cuando bajamos de nivel, nos
encontramos con empresas ms pequeas, ms inestables, ms riesgosas y ms difciles de
predecir, con grandes inconvenientes para tomar buenas decisiones.
9 Project Manager, Lder o Facilitador: Un Gerente de Proyecto debe desarrollar
diferentes roles por lo que es importante la ptima aplicacin de sus habilidades personales.
Normalmente un PM debe cumplir con su rol de Gerente pero adems debe tambin ser el
Lder del grupo de trabajo, aspectos que tienen distintos objetivos. El lector debera conocer
la importancia del proceso de Team Building y cmo los grupos van madurando a lo

Seikko Grupo Business

largo del desarrollo del proyecto. Actualmente tambin podemos clasificar a los equipos de
trabajo conforme a su capacidad tcnica y resolutiva, llegando a tener equipos de trabajo
denominados de Alto Desempeo en donde los conflictos los resuelven entre ellos, toman
decisiones propias y pueden autogestionarse. En estos casos el rol del PM ms importante
es el de Facilitador donde lo que prima es dejar trabajar con libertad y preocuparse ms en
eliminar los problemas u obstculos del equipo. Las caractersticas de los facilitadores son:
Lideran pero no dominan; utilizan mucha escucha activa; motivan a la participacin y
trabajo cooperativo; lideran con el ejemplo; mantienen al sponsor activamente involucrado
pero se aseguran que no interfiera en el trabajo; documentan al nivel necesario. Estamos
hablando de gente de alta confianza y estima que demuestran carisma, empata, respeto y
sensibilidad por el grupo de trabajo. Podemos decir entonces que otro factor clave en la
gestin de los proyectos es colocarse el sombrero adecuado teniendo en cuenta el tipo de
proyecto, el team de trabajo o las circunstancias especiales que estemos controlando.

Seikko Grupo Business

LDER

MANAGER

FACILITADOR

Focalizado en hacer que Focalizado en lograr el

se haga bien el trabajo trabajo correcto

Focalizado en ayudar a
la gente en el logro del
trabajo

Se concentra en el qu

Ayuda a la gente a

Se concentra en el

y el por qu

cmo

concentrarse

Establece la Direccin
y Metas

Establece el Plan

Ayuda a la gente a
entender la Direccin y
Metas

Se asegura que los otros Ordena a los otros a

respondan y lo sigan
completar sus tareas

Se asegura que los otros

se comprometan en las
tareas

Inspira, motiva, incita

creacin e innovacin

Ayuda a la gente a
resolver sus problemas
eliminando barreras

Ejecuta, controla,
gestiona, resuelve
problemas

10 Project Management Estratgico: el tema se basa en asegurarse de que todos los

proyectos estn estratgicamente alineados y fueron previamente analizados por la PMO o
un proceso de PPM. Se debe definir un criterio contra el cual todos los proyectos pueden
ser priorizados que incluya el impacto en las estrategias corporativas y los clientes, y
confeccionar una lista de todos los proyectos, sus metas y objetivos estratgicos. Despus,
tratar de identificar el criterio de xito de los mismos y determinar el impacto esperado que
cada proyecto tendr en la organizacin y sus clientes. Asignar un rango para cada proyecto
cuantitativamente y determinar su nivel de prioridad. Alinear los proyectos con los planes
estratgicos corporativos y departamentales, y ejemplificar cmo la ejecucin exitosa de
cada proyecto apoyar la estrategia corporativa o departamental. En ciertos casos no queda
otra salida que cancelar los proyectos que son de baja prioridad o que no estn ligados al
plan estratgico de la corporacin o del departamento. Qu se puede hacer para
implementar las mejores prcticas de Project Management Estratgico?: la retencin del
conocimiento es uno de los mayores beneficios para las organizaciones ya que contribuye

Seikko Grupo Business

al aprendizaje continuo y ayuda a evitar la repeticin de errores. Con objeto de retener el

conocimiento sobre la implementacin efectiva de proyectos y que puedan ser pasados
como lecciones aprendidas hacia equipos de proyectos a futuro, la PMO debera tener una
reunin de cierre de proyecto tan pronto como haya terminado, mientras el conocimiento
sobre la administracin del mismo an est fresco en las mentes de todos. El propsito de
esta reunin es revisar qu sucedi durante el transcurso del proyecto y qu puede aprender
el equipo y la organizacin de lo sucedido. El sponsor del proyecto, el responsable del
proyecto y el equipo de trabajo debern estar presentes as como cualquier recurso exterior
o stakeholders quienes quisieran contribuir con ideas. El resultado final de esta reunin
de cierre del proyecto ser la creacin de un documento formal de lecciones aprendidas

para ser llevadas a proyectos futuros, a los gerentes y a sus equipos de trabajo. El
establecimiento de mediciones de proyectos exitosos desde el punto de vista estratgico
tambin ayudar a proveer a la alta direccin de informacin relevante y necesaria para
tomar decisiones que afecten el proyecto. Por ejemplo, la presentacin estratgica de las
medidas del xito del proyecto puede convencer a la alta direccin de re-priorizar proyectos
o de re-asignar recursos. Las medidas del xito del proyecto proveern a la PMO de la
informacin necesaria para que venda el impacto de la efectividad al nivel gerencial. Los
criterios para el xito en la medicin de los proyectos estratgicos deben incluir:

La utilizacin de un criterio de calidad especificado.

La habilidad para enfrentar cambios en los requerimientos.

El nmero de recursos usados actualmente contra el nmero de recursos anticipados

originalmente.

La habilidad del proyecto para alcanzar sus objetivos y entregables especficos.

Las encuestas de satisfaccin de clientes que indican su conformismo con el

producto o la entrega del servicio del proyecto.

La puesta en produccin o lanzamiento exitoso y sin problemas.

Mediciones financieras adecuadas y dentro de los lmites.

Finalmente, para las organizaciones que estn considerando en definir cul es la mejor
metodologa para administrar sus proyectos, o cmo adaptar la metodologa del PMBOK
a sus propias necesidades, la recomendacin es considerar un buen programa de
entrenamiento de sus PM y considerar su posible certificacin, que ofrezca una revisin de
la metodologa y las reas claves para su organizacin: costos, tiempos, riesgos, calidad,
junto con una visin ms amplia, crtica y realista. Otra alternativa es contratar a una
organizacin con consultores especializados y certificados PMP para que colaboren en la
implementacin de los proyectos y realicen la transferencia de conocimientos y prcticas
necesarias.