curso administración de proyectos (noviembre)

8/20/2019 Curso Administración de Proyectos (Noviembre)

http://slidepdf.com/reader/full/curso-administracion-de-proyectos-noviembre 1/23

CURSO DE ADMINISTRACION

PROYECTOS

Seikko – Grupo Business



La Empresa

Seikko - Grupo Business es una consultoría seria y de reconocido prestigio

dedicada a la asesoría, consultoría y gestoría financiera y administrativa

empresarial y gubernamental. Tenemos a disposición de nuestros clientes,

profesionales con experiencia y un excelente currículum ue est!n en constanteperfeccionamiento para poder brindar el me"or servicio, profesional y el trato

excelente ue nuestros clientes merecen.

#on una visión sustentada en escuc$ar a nuestros clientes, acercamos a cada

cliente soluciones pensadas exclusivamente para sus necesidades %rofesionales.

&xpertos en #us$ing empresarial e institucional, con m!s de '( a)os de

experiencia en los sectores p*blico, privado y social.




Administración de Proyectos

La administración de proyectos es la disciplina de gestionar proyectos exitosamente, lacual puede y debe aplicarse durante el ciclo de vida de cualquier proyecto (Dixon,2000).

A lo largo de esta sección se abordaran temas relacionados con la administración de

proyectos, sus etapas, y otras consideraciones para comprender a grandes rasgos elobetivo de esta disciplina.

Definición de Administración de Proyectos

!xisten varias de"iniciones de la Administración de proyectos, a continuación semuestran algunas#

De acuerdo con una enciclopedia en l$nea, la administración de proyectos es ladisciplina que se encarga de de"inir y alcan%ar obetivos optimi%ando el uso derecursos# tiempo, dinero, la gente, espacio, etc. (Project management., 200&).

'tra de"inición nos dice que# la administración de proyectos es la "orma de planear,organi%ar, dirigir y controlar una serie de actividades reali%adas por un grupo depersonas que tienen un obetivo especi"ico el cual puede ser (crear, disear, elaborar,meorar, anali%ar, etc.) un problema o cosa (*odr$gue%, 2002).

Distinción entre una Metodología de Administración de Proyectos y unaMetodología de Desarrollo de Software

!s importante establecer una distinción entre una metodolog$a de Administración deproyectos y una metodolog$a de desarrollo de so"t+are. La importancia de distinguir

entre ambos conceptos radica en que una organi%ación debe contar con unametodolog$a de administración de proyectos consistente a cualquiera que sea lanaturale%a del proyecto que se desarrolla. Las di"erencias entre ambos conceptos seenlistan en la Tabla 1 (eville, 200&).




Metodología de Administración deProyectos

Metodología de Desarrollo deAplicaciones

Dice que los proyectos deben ser divididos en"ases y antes de iniciar con cada una de ellas

debe existir un plan

!stablece cu-les son las "ases y quactividades involucra

De"ine roles y responsabilidades De"ine cu-les son los roles yresponsabilidades que corresponden acada "ase

Dice que un pre supuesto debe ser de"inido yadministrado.

De"ine qu medidas deben emplearsepara contabili%ar el desarrollo en laorgani%ación.

!l proceso de administración de proyectos recibe como entradas o es a"ectado por(Dixon, 2000)#

• ecesidades y requerimientos del proyecto a desarrollar (alcance).

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

legales, etc.

• /ecanismos para lograrlo entre los que est-n# personas, tcnicas, err

amientas, equipo y organi%ación.




!n base al desempeo de dica Administración se entreganproductos o servicios como salida, tal como se observa en la Figura1.

Figura 1 . 1roceso de Administración de 1royectos. uente# (Dixon, 2000)




Fases de la administración de Proyectos

!n la perspectiva tradicional, es posible distinguir & componentes de un proyecto (3etapas m-s el control) en el desarrollo de un proyecto (Project management. 200&)#

4.5 6niciación de proyecto

2.5 1lani"icación de proyecto

7.5 1roducción de proyecto oeecución

3.5 8upervisión y control del 1royecto

&.5 inali%ación de proyecto o cierre

o todos los proyectos visitar-n cada etapa ya que los proyectos pueden ser

terminados antes de que alcancen la "inali%ación. Algunos proyectos probablemente notienen la plani"icación y9o el control. : algunos proyectos pasar-n por pasos 2, 7 y 3varias veces (Project management. 200&).

Fases del desarrollo de Software

1or otra parte, una de varias metodolog$as disponibles para el desarr ollo de sistemasse compone por las siguientes "ases (*odr$gue%, 2002)#

• 6nvestigación 1reliminar

• Diseo del 8istema

• Desarrollo de 8istemas

• 1ruebas del 8istema

• 6mplantación y evaluación




/ucas metodolog$as var$an en las "ases que involucran y pueden reali%ar procesos deretroalimentación o iterativos asta lograr tener un producto deso"t+are terminado. 8ea cual sea la metodolog$a, "inalmente sebusca producir una aplicación lista para su uso.

!l proceso de administración de proyectos recibe como entradas oes a"ectado por (Dixon, 2000)#

• ecesidades y requerimientos del proyecto a desarrollar (alcance).

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

legales, etc.

• /ecanismos para lograrlo entre los que est-n# personas, tcnicas, err

amientas, equipo y organi%ación.

!n base al desempeo de dica Administración se entregan productos o servicios comosalida, tal como se observa en la Figura 1.




Figura 1 . 1roceso de Administración de 1royectos. uente# (Dixon, 2000)

Fases de la administración de Proyectos

!n la perspectiva tradicional, es posible distinguir & componentes de un proyecto (3etapas m-s el control) en el desarrollo de un proyecto (Project management. 200&)#

4.5 6niciación de proyecto

2.5 1lani"icación de proyecto

7.5 1roducción de proyecto oeecución

3.5 8upervisión y control del 1royecto

&.5 inali%ación de proyecto o cierre




o todos los proyectos visitar-n cada etapa ya que los proyectos pueden serterminados antes de que alcancen la "inali%ación. Algunos proyectos probablemente notienen la plani"icación y9o el control. : algunos proyectos pasar-n por pasos 2, 7 y 3varias veces (Project management. 200&).

Éxito y fracaso en proyectos de desarrollo de software

8in considerar el tamao del proyecto, su alcance o duración existen & m-ximas desatis"acción en su desarrollo (;oyd, 2004)#

• !ntregar el producto que el cliente desea o necesita

• !ntregar la calidad de manera acorde con el precio

• !ntregar el producto en el espacio de tiempo que el cliente desea o necesita

• !ntregar el nivel de retroalimentación que el cliente desea, y

• <ontar con un sistema de resolución de con"lictos usto para el cliente y el

equipo de desarrollo

Los que se consideran como pa sos b-sicos esenciales para lograr una administracióne"iciente de proyectos se enumeran a continuación (=oledo, 2002)#

1or otro lado los aspectos cr$ticos que contribuyen al "racaso de proyectos de

tecnolog$as de in"ormación incluyen (;roc>, ?endric>s, Linnell, @ 8mit, 2007) #

4.5 unca iniciar sin un obetivo bien de"inido

2.5 ragmentar el proyecto

7.5 6nvertir tiempo en la planeación

3.5 6nvolu crar al equipo de trabao en la planeación y elcontrol

&.5 omentar la coesión del equipo de trabao

.5 1revenir problemas



B.5 Antes de eecutar, establecer l$neas de ;ase.

C.5 /antener claro el obetivo principal del proyecto.

.5 !stablecer un proceso para monitorear y controlar

40.5 Atender los puntos cr$ticos primordialmente.

44.5 =omarse el tiempo necesario para cerrar el proyecto.

42.5 Etili%ar una metodolog$a para todos los proyectos.

• alta de visión clara y establecimiento adecuado de requerimientos

• !xpectativas irreales

• alta de descomposición del proyecto

• 1ol$ticas inadecuadas de selección de personal y con"lictos en el equipo de

desarrollo.

• alta de involucramiento y en"oque acia el cliente

• alta de en"oque estratgico y apoyo administrativo

=anto los pasos b-sicos para reali%ar una administración proyecto como los aspectoscr$ticos que provocan "racasos en este proceso de desarrollo deben de sercontemplados y corregidos, de acuerdo a la "orma de trabaar de la empresa. De estamanera se busca meorar el proceso de desarrollo de los proyectos de so"t+are ytomar en cuenta aquellas "allas comunes.




PROCESOS CLAVES EN LA

ADMINISTRACION DE PROYECTOS

1 - Seguir un proceso de iniciación estructurado: realizar un estudio de factibilidadfinanciero, tecnológico, de recursos, impactos, estratégico y de negocio del proyecto, para prevenir inconvenientes, priorizarlo y obtener el soporte y justificación de negocionecesario para poder implementarlo. Durante la fase de inicio o arranque, una correctavaloración de riesgos, asunciones, obstáculos y restricciones deben ser convenientementeevaluados y el factor crítico es realizar un adecuado proceso de valoración derequerimientos (!" para clarificar objetivos, necesidades y alinear las e#pectativas. $n

muc%os casos los procesos de ! pueden automatizarse pero siempre es convenientemantener sesiones y reuniones con los sta&e%olders para aclarar los puntos grises. 'odas lasmetodologías de administración de proyectos recalcan la importancia de una fuerte relacióncon los sta&e%olders y su proceso de análisis, dado que con ellos podremos lograr másfácilmente el é#ito y romper diversas barreras en los proyectos. n error frecuente es quemuc%os proyectos pueden tener un gran n)mero de sta&e%olders y el team sólo dialoga conaquel más sociable y entusiasta sin evaluar las e#pectativas de los otros que directa oindirectamente están involucrados y son precisamente los que pueden ponernos los palos en




la rueda. n factor com)n para el é#ito de los proyecto es poseer la%abilidad de negociar y manejar las e#pectativas y necesidades de lossta&e%olders afectados por el proyecto. *a relación con el sponsor y lossta&e%olders es vital y la clave es establecer una buena +relación lo queimplica más que identificar y manejar sus e#pectativas, manejar una

cone#ión emocional con la gente. $l -! debe focalizarse en mejorar sus %abilidades

interpersonales, y asegurarse de que todos los sta&e%olders están a bordo del proyectomanteniendo fluida comunicación con ellos. $l análisis de los sta&e%olders debería permitir al -! no sólo identificarlos sino categorizarlos bajo distintos aspectos relación y actitud

%acia el proyecto, están a favor o en contra del proyecto, cuál es su poder e influencia,e#isten conflictos entre ellos, etc.

2 - Planificación del Proyecto: de acuerdo a la industria donde se realice el proyecto, la planificación podrá tomar diferentes matices. *os proyectos para el desarrollo de soft/areson bastante particulares, tan es así, que surgieron metodologías propias para los mismos(+0gil Development" diferentes a las tradicionales como el -!1234. 0lgunos aspectosde las metodologías ágiles pueden ser utilizados en cualquier otro proyecto. 0ctualmenteestá de moda %ablar también de *ean 5i# 5igma -roject !anagement, otra apro#imación ala gestión efectiva de proyectos. 6ndependientemente de que se utilice una metodologíatradicional, ágil o lean7 una buena planificación siempre es necesaria. $n la metodologíatradicional la planificación es e#%austiva y completa, en los ciclos más acelerados ylivianos (ágil o lean" la planificación se concentra en delimitar los bordes del proyecto paracrear una lista priorizada de entregables que serán liberados en fases de tipo iterativa.-lanes comprensivos, realistas y bien comunicados son imprescindibles en todos los proyectos, a)n con cortos ciclos de vida. 6nvolucrar no sólo al team sino a los sta&e%oldersen el desarrollo de los planes, discutir acerca de todos los objetivos y entregables del proyecto y e#plicar claramente los riesgos involucrados son también factores esenciales.8omo corolario final el consejo es no embarcarse en planificaciones e#tensas, construir planes a corto plazo y detallados (elaboración progresiva seg)n el mismo -!1234", e ir elaborando los requerimientos sobre la marc%a en una apro#imación de tipo iterativo.

3 - Utilizar auditorías: para evaluar la salud del proyecto, deberían realizarse auditorías yreuniones de +quality assurance en forma frecuente para c%equear no sólo los entregablessino el estado y progreso del proyecto. !edir el progreso real versus el costo y tiempoestimado es muy importante, al igual que realizar mediciones de calidad respecto delcumplimiento de los requerimientos y el alcance de los entregables. 9o podemos controlar y muc%o menos mejorar si no tenemos métricas. Debemos desarrollar criterios estándar demedición tanto de calidad como de productividad y eficiencia, para saber no sólo dóndeestamos sino qué y cómo debemos mejorar. $l -! debe desarrollar todas las actividades y procesos definidos dentro del grupo de !onitoreo y 8ontrol del -royecto que involucra el




control del progreso del mismo (tiempo y tareas", el control del alcance(cambios", control del rendimiento (performance", control de los costos(método del valor ganado" y el control de calidad. De dic%os controlessurgirán reportes y medidas correctivas o preventivas.

*as auditorías también pueden ser efectuadas por personal e#terno al proyecto, y sedenominan +peer revie/s, realizadas por colegas o el departamento -!2 o de

0seguramiento de 8alidad. $l alcance de la misma debería ser similar al comentado másarriba. 'oda auditoría consta de las siguientes etapas

• Planificación: $lección del tipo de auditorías a realizar (costos, performance,calidad, etc.", determinar los procedimientos a utilizar, elección del personal,fijación de su periodicidad (mensual, anual, esporádica, etc.".

• Realización de auditorías según procedimiento y plan definidos: $s convenientedesde el punto de vista práctico que la realización de auditorías sea sistemática, y el propio director o responsable del área a auditar transmita a sus subordinadosafectados las fec%as concretas en las que estas auditorías sistemáticas van arealizarse para que presten su mayor colaboración. *os documentos que recaben losresultados de las auditorías, es decir, respuestas, comprobaciones, resultados demedidas y ensayos, etc., %an de estar consensuados entre auditor y auditado, de talforma que recojan la conformidad de ambos, evitándose discusiones in)tiles. 5etrata de auditar la efectividad de la gestión del proyecto, tanto a través del grado decumplimiento de los procesos, como a través de la calidad del producto obtenido.




• !aluación de los resultados de la auditoría: 'oda auditoría %a de realizarse paraobtener una nota final que sirva, aunque sólo sea comparativamente, para medir laevolución y progreso del proyecto. *o que se pretende es la obtención de unavaloración totalmente objetiva por lo que el sistema de valoración %a de ser consensuado, y además, e#perimentado durante cierto tiempo, para poder fijar las

se:ales de alerta, índices de ponderación, etc.

• Redacción de un informe y propuesta de medidas correcti!as de ser necesario"

con e#presión de su grado de urgencia: na vez valorada la auditoría y antes dela redacción del informe final y propuesta de las medidas correctoras, esconveniente la reunión con el -! afectado por la auditoría para que sea el primer

informado y pueda incluso colaborar en la propuesta de medidas correctoras así como ladecisión sobre la urgencia de las mismas, pues es conveniente que tanto el informe de laauditoría como la propuesta de medidas correctoras, lo asuma como algo propio, entreotras cosas porque a veces, podrá ejercer más presión sobre la ;erencia que el propioauditor, sobre todo si alguna de las medidas propuestas corresponden o requiereninversiones.

$ - Utilización de recursos %umanos: la correcta utilización de las +técnicas blandas y eluso adecuado de las %abilidades interpersonales son factores críticos en el manejo de todos

los proyectos. n tema controversial que suele traernos dolores de cabeza se refiere a las%oras que cargan los recursos al proyecto <deben ser las reales o teóricas=. $n lasorganizaciones en las que trabajé, como ocurre con muc%as consultoras o empresas deservicios, al cliente se le cobra de acuerdo al proyecto un +precio fijo o +time > material(por %ora de consultoría". $n ambos casos se toma para la formación del precio el +costrate de los recursos que trabajarán en el proyecto, independientemente de que el recurso pertenezca o no a la organización ejecutante. 5i pertenece a la organización y trabaja másde ?@ %oras a la semana, su salario será siempre el mismo, pero a los efectos de cobro alcliente en el caso de time > material podríamos cobrar las %oras +overtime, algo que, en la práctica sólo se le paga al recurso si es e#terno a la organización. $n los casos de preciofijo, durante la planificación normalmente calculamos en la %erramienta de sc%eduling ?@

%oras de trabajo semanal. 5i observamos que e#isten recursos con sobre alocación (más deA %oras por semana" la técnica más com)n a utilizar sería el resourceBleveling algo quegeneralmente terminará por enviarnos el final del proyecto al lado oscuro de la luna. $n la práctica normalmente no se %ace nada dado que el recurso si es parte de la plantilla de laorganización, trabajará esas %oras e#tras que por lo general y debido a su rango no son pagadas en la práctica dado que recibe su sueldo mensual fijo. $l problema se presentacuando e#isten sistemas de control de costos y productividad que no toma en cuenta estarealidad (dado que se maneja con planillas separadas". $n estos casos es frecuente que se le




obligue al recurso a cargar las %oras que realmente trabaja en el proyectoen alg)n sistema para su registro. De ser así, estaremos en un aprietodesde el punto de vista de costos, dado que las %oras cargadas y costeadassuperarán lo que estaríamos facturando. *a )nica solución en este casoserá que no cargue sus %oras e#tras, bajando su nivel de +billability, algo

que no sólo puede perjudicar al recurso sino también al mismo gerente (problemas deutilización y productividad". 2tro tema importante es la no disponibilidad de los recursosclaves (algo frecuente en los proyectos de alta tecnología". *a 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".

& - stimación en los Proyectos: las estimaciones de costos y tiempos en un proyectoconstituyen la parte más difícil en la planificación, y es más un arte que una ciencia. 8omoconsultor tuve que realizar una revisión a un proyecto que estaba con un sobrecosto muyelevado y querían un análisis de la causa de la variación del mismo. !i primera preguntafue +cuál era el método que utilizaban para las estimaciones, la respuesta clásica fue el proyecto tiene que estar listo para 2ctubre y se vendió en este precio considerando una

determinada carga de recursos. !i segunda pregunta fue +<si la base de estimación es unaficción, como quiere que la varianza en el costo tenga alg)n significado=.*amentablemente muc%as organizaciones venden sus proyectos de acuerdo a lo establecido por Centas y no tienen tiempo de realizar una estimación bottomBup o utilizar buenastécnicas de métodos cuantitativos de administración de proyectos para al menos estimar lasvariaciones e incertidumbres con los buffers de contingencias necesarios. 8uanto máslargos en recursos, tiempo, costos o complejidad son los proyectos muc%o más complicadaresultará la realización de las estimaciones. $l 5tandis% ;roup a través de sus estudiosempíricos nos arroja estos resultados de é#itofracaso de proyectos en su relación con sutama:o y duración.

'ama:o del proyecto -ersonas 'iempo (meses" -orcentaje de é#ito




'e(a)o de *+&, . . &&/

*+&,-*10& 12 33/

*10&-*3 2& 12 2&/

*3-*. $, 1 1&/

*.-*1, 42&, 42$ /

5*1, 4&,, 43. ,/

$sto nos demuestra una vez más que los megaBproyectos pasaron de moda y que eldesarrollo iterativo es el mejor método para mitigar riesgos y una estrategia buena paraestimar mejor el alcance, costo y tiempo de los entregables a distribuír en el proyecto.

. - Practicar un estricto control de cam(ios: independientemente del tama:o del proyecto y para evitar el +5cope 8reep se deberá ser muy riguroso en lo que respecta alcontrol y seguimiento de los cambios al proyecto, utilizar %erramientas automáticas de !

(equirement !anagement" y 8! (8onfiguration !anagement". 'ener muy claro el procedimiento para solicitar los cambios, el tipo de formulario, cómo debe ser completadoy el método para aprobación respectivo. 5i el ;erente de -royecto no %a definido bien elalcance inicial del proyecto, será tremendamente difícil administrar el mismo. $l propósitode la administración de cambios es proteger la viabilidad de la definición del proyecto yadefinida y aprobada. 8uando se solicita formalmente un cambio implica que dic%o cambioestá fuera del alcance acordado en la definición del -royecto o de los requerimientos osolicitudes detallados durante el análisis. 5i dic%o alcance es confuso, poco claro, o dejalugar a interpretaciones, entonces el cliente dirá que el cambio está dentro del alcance, y el;erente de -royecto encontrará difícil apegarse a un proceso formal de ;estión de 0lcance.$n algunos proyectos es posible anticipar todas las solicitudes y requerimientos durante el

proceso de análisis. 9o obstante lo cual, siempre podrá e#istir la posibilidad y la necesidadde incorporar cambios durante el ciclo de vida. $stos cambios pueden ser muy necesarios para la solución, y pueden e#istir razones poderosas de negocio por las que deberíanincorporarse. $l ;erente de -royecto y el equipo de trabajo, deben reconocer el momentoen que los cambios son requeridos y deberán seguir un proceso predefinido de gestión delalcance. $ste proceso, eventualmente, proporcionará información para que el sponsor tomelas decisiones pertinentes y también le permitirá decidir si la modificación deberá aprobarseen base al valor e impacto en el proyecto en términos de costo y tiempo. Debe ser claro




para todas las partes que cumplir estos nuevos requerimientos con losmismos recursos de la definición anterior, es prácticamente imposible.

+ - 6uffers: incertidum(re" pro(a(ilidades: son temas que %acen a lagestión cuantitativa de los proyectos. -rimero y fundamental es necesario

no mezclar (al menos sin identificar claramente" las contingencias que nostomamos en las estimaciones con la duración puesta a cada tarea. $sta contingencia debeser claramente identificada y manejada para evitar el efecto de la famosa +*ey de-ar&inson. $l método de la 8adena 8rítica coloca todas estas contingencias en un buffer compartido para todo el proyecto de uso e#clusivo del -!. De no utilizar este método el-!1234 nos aconseja utilizar contingencias o buffers por las incertidumbres en lasestimaciones utilizando 8-!-$', !onte8arlo, Carianza de la media, o simplemente un porcentaje del total de costo o tiempo adicional. $l cálculo del tama:o del buffer debe tener en cuenta muc%os factores. Eablar de incertidumbre en riesgos o en las estimaciones no ese#actamente lo mismo que %ablar de cuál sería la probabilidad de ocurrencia. $n formasimple, al arrojar una moneda e#iste una incertidumbre respecto de si saldrá cara o ceca.-ero no %ay incertidumbre respecto de las probabilidades de que salga cara dado que ambastienen un F@G. 5i la probabilidad de un

evento se acerca más al H@@G estaremos muc%o más tranquilos porque reducimos suincertidumbre, pero inevitablemente aumentaremos su rango. -or ejemplo, si tenemos una pieza mecánica que a través de mediciones %ec%as durante F a:os sabemos que puedecausar da:os %umanos en un impacto con rango del IFG al ?FG (H@G" y esto no esaceptable, lo que ocurrirá es que se realizarán tareas de ingeniería para mejorar dic%a piezay reducir ese impacto negativo. 5upongamos que logramos armarla de otra forma y quea%ora las probabilidades de que ocurra algo malo son del rango entre FG y JFG (J@G".Eemos reducido significativamente la probabilidad de un accidente pero como no %ay%istoria pasada el rango de la incertidumbre es más alto (del H@ al J@G".

- Su(contratar desarrollos e#ternos 789utsourcing;: muc%as veces %e trabajadocomo +prime contractor en proyectos en donde teníamos muc%os proveedoresinvolucrados (en algunos casos, su desarrollo era más importante que el nuestro". $n esteaspecto son válidas todas las recomendaciones del -!1234 sobre adquisiciones, ademásde tener en cuenta todas las modalidades contractuales y de mantener el +pari passu(mismas condiciones de obligaciones y responsabilidades contractuales" de las cláusulas delcliente con nuestros proveedores. $n este caso me referiré a un tema muy corriente en elambiente de 6' que es la e#igencia de ciertos niveles de calidad (8!!6" que se suelerequerir cuando se contrata o se %ace un outsourcing. *a mayoría de las empresas %oy endía pregonan ser certificadas en 8!!6. $sto es imposible dado que 8!!6 no es una




certificación, el 5$6 no certifica organizaciones como el 652 o el 6'5!K,sino que autoriza a personas denominadas +lead appraisers a conducir auditorías para determinar el grado de madurez de la organizaciónrespecto del modelo. $l 5$6 no confirma la certeza del nivel de madurezreportado, sino que su foco es más bien la calidad continua de la

organización, que identifique en qué nivel se encuentra y que realice todos los esfuerzosnecesarios para mejorar su calidad y %acer sus procesos repetibles.

Datos de desempe:o

6ndia Lapón$stadosnidos

$uropa yotros

'otal

<úmero de proyectos 2$ 2+ 31 22 1,$

Programador =9>?9 2, $. 2+, $3. 3+$

ediana de índice por

defecto?=9>02.3 0,2, 0$,, 022& 01&,

$l gráfico mostrado más arriba es un informe del 6$$$ 5oft/are que documenta un estudio

sobre H@? proyectos de soft/are en el mundo. 6ndia es el país que proclama tener lamayoría de sus empresas con 9ivel F de 8!!6 y sin embargo está en el tercer lugar encuanto a programas con errores (el informe incluye empresas como !otorola 6ndia,6nfosys, 'ata 8onsulting", <algo como para tener en cuenta no=. 9o estoy desmereciendo laevaluación del modelo de madurez sino que debería preguntarse muc%o acerca de cómo seobtuvo y otras cuestiones de la empresa a contratar tales como

• <8uándo fue publicado su )ltimo assessment= (dura J a:os"

• 8opia de la documentación donde figura <qué áreas son las más fuertes y cuáles conlas más débiles=.

• <Muién desarrolló el lead assessment=

• <8uáles son sus planes de mejora continua=

• <8on qué otros clientes trabaja=




2tra característica asociada a la inmadurez de nuestro mercado es el error de escuc%ar a un gerente decir +esta tarea ya no representa un problema porque la %emos subcontratado. $sto es falso, fundamentalmente porquela inestabilidad de nuestro mercado %ace que sea muy difícil desarrollar relaciones cliente N proveedores que perduren en el tiempo. -or otro lado,

esta inestabilidad y lo peque:o del mercado generan el problema que los proveedores engran medida sean -ymes, y éstas permanentemente deben de tener una muy agresiva actitudde venta, sobre todo si son proveedores que dependen de la aparición de proyectos en elmercado para tener trabajo y resulta muy difícil su evaluación porque no %ay una manerasimple de saber el estado en que se encuentra dic%o proveedor. $s posible analizar loscontratos que tiene en ejecución, pero no es posible analizar los contratos que +están a lafirma, y muc%as veces la concreción de uno, genera mejores condiciones en las -ymes para enfrentar las negociaciones con los otros contratos, y se produce una cascada decontratos que se firman, una cantidad de compromisos simultáneos que este proveedor tieneque cumplir, y como generalmente no cuenta con reservas de recursos %umanos ni con una planificación previa tiene como resultados crisis de recursos y falta de cumplimiento entodos los contratos. $n el caso a su vez que el contratista subBcontrate el servicio en otraorganización se le suma a la inestabilidad propia del contratista, que tiene sus crisisinternas, las que potencian a la de los subcontratistas. 8uando bajamos de nivel, nosencontramos con empresas más peque:as, más inestables, más riesgosas y más difíciles de predecir, con grandes inconvenientes para tomar buenas decisiones.

@ Pro)ect anager" =íder o Aacilitador: n ;erente de -royecto debe desarrollar diferentes roles por lo que es importante la óptima aplicación de sus %abilidades personales. 9ormalmente un -! debe cumplir con su rol de ;erente pero además debe también ser el*íder del grupo de trabajo, aspectos que tienen distintos objetivos. $l lector debería conocer la importancia del proceso de +'eam 1uilding y cómo los grupos van madurando a lo

largo del desarrollo del proyecto. 0ctualmente también podemos clasificar a los equipos detrabajo conforme a su capacidad técnica y resolutiva, llegando a tener equipos de trabajodenominados de 0lto Desempe:o en donde los conflictos los resuelven entre ellos, tomandecisiones propias y pueden autogestionarse. $n estos casos el rol del -! más importantees el de Kacilitador donde lo que prima es dejar trabajar con libertad y preocuparse más eneliminar los problemas u obstáculos del equipo. *as características de los facilitadores son*ideran pero no dominan7 utilizan muc%a escuc%a activa7 motivan a la participación ytrabajo cooperativo7 lideran con el ejemplo7 mantienen al sponsor activamente involucrado pero se aseguran que no interfiera en el trabajo7 documentan al nivel necesario. $stamos%ablando de gente de alta confianza y estima que demuestran carisma, empatía, respeto ysensibilidad por el grupo de trabajo. -odemos decir entonces que otro factor clave en lagestión 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.




*OD$ !090;$ K086*6'0D2

Kocalizado en %acer quese %aga bien el trabajo

Kocalizado en lograr eltrabajo correcto

Kocalizado en ayudar ala gente en el logro deltrabajo

5e concentra en el qué 5e concentra en el 0yuda a la gente a




y el por qué cómo concentrarse

$stablece la Direccióny !etas

$stablece el -lan 0yuda a la gente aentender la Dirección y!etas

5e asegura que los otrosrespondan y lo sigan

2rdena a los otros acompletar sus tareas

5e asegura que los otrosse comprometan en lastareas

6nspira, motiva, incitacreación e innovación

$jecuta, controla,gestiona, resuelve problemas

0yuda a la gente aresolver sus problemaseliminando barreras

1, @ Pro)ect anagement stratBgico: el tema se basa en asegurarse de que todos los proyectos están estratégicamente alineados y fueron previamente analizados por la -!2 oun proceso de --!. 5e debe definir un criterio contra el cual todos los proyectos pueden

ser priorizados que incluya el impacto en las estrategias corporativas y los clientes, yconfeccionar una lista de todos los proyectos, sus metas y objetivos estratégicos. Después,tratar de identificar el criterio de é#ito de los mismos y determinar el impacto esperado quecada proyecto tendrá en la organización y sus clientes. 0signar un rango para cada proyectocuantitativamente y determinar su nivel de prioridad. 0linear los proyectos con los planesestratégicos corporativos y departamentales, y ejemplificar cómo la ejecución e#itosa decada proyecto apoyará la estrategia corporativa o departamental. $n ciertos casos no quedaotra salida que cancelar los proyectos que son de baja prioridad o que no están ligados al plan estratégico de la corporación o del departamento. <Mué se puede %acer paraimplementar las mejores prácticas de -roject !anagement $stratégico= la retención delconocimiento es uno de los mayores beneficios para las organizaciones ya que contribuye

al aprendizaje continuo y ayuda a evitar la repetición de errores. 8on objeto de retener elconocimiento sobre la implementación efectiva de proyectos y que puedan ser pasados

como lecciones aprendidas %acia equipos de proyectos a futuro, la -!2 debería tener unareunión de cierre de proyecto tan pronto como %aya terminado, mientras el conocimientosobre la administración del mismo a)n está fresco en las mentes de todos. $l propósito deesta reunión es revisar qué sucedió durante el transcurso del proyecto y qué puede aprender el equipo y la organización de lo sucedido. $l sponsor del proyecto, el responsable del proyecto y el equipo de trabajo deberán estar presentes así como cualquier recurso e#terior o +sta&e%olders quienes quisieran contribuir con ideas. $l resultado final de esta reuniónde cierre del proyecto será la creación de un documento formal de +lecciones aprendidas




para ser llevadas a proyectos futuros, a los gerentes y a sus equipos de trabajo. $lestablecimiento de mediciones de proyectos e#itosos desde el punto de vista estratégicotambién ayudará a proveer a la alta dirección de información relevante y necesaria paratomar decisiones que afecten el proyecto. -or ejemplo, la presentación estratégica de lasmedidas del é#ito del proyecto puede convencer a la alta dirección de reBpriorizar proyectos

o de reBasignar recursos. *as medidas del é#ito del proyecto proveerán a la -!2 de lainformación necesaria para que venda el impacto de la efectividad al nivel gerencial. *oscriterios para el é#ito en la medición de los proyectos estratégicos deben incluir

• *a utilización de un criterio de calidad especificado.

• *a %abilidad para enfrentar cambios en los requerimientos.

• $l n)mero de recursos usados actualmente contra el n)mero de recursos anticipadosoriginalmente.

• *a %abilidad del proyecto para alcanzar sus objetivos y entregables específicos.

• *as encuestas de satisfacción de clientes que indican su conformismo con el producto o la entrega del servicio del proyecto.

• *a puesta en producción o lanzamiento e#itoso y sin problemas.

• !ediciones financieras adecuadas y dentro de los límites.

Kinalmente, para las organizaciones que están considerando en definir cuál es la mejor metodología para administrar sus proyectos, o cómo adaptar la metodología del -!1234a sus propias necesidades, la recomendación es considerar un buen programa deentrenamiento de sus -! y considerar su posible certificación, que ofrezca una revisión dela metodología y las áreas claves para su organización costos, tiempos, riesgos, calidad, junto con una visión más amplia, crítica y realista. 2tra alternativa es contratar a unaorganización con consultores especializados y certificados -!-4 para que colaboren en laimplementación de los proyectos y realicen la transferencia de conocimientos y prácticasnecesarias.

curso administración de proyectos (noviembre)

Documents