1gerencia de proyectos

8/3/2019 1gerencia de proyectos

1/16

REPUBLICA BOLIVARIANA DE VENEZUELAUNIVERSIDAD NACIONAL EXPERIMENTAL

RAFAEL MARIA BARALTPROGRAMA INGENIERIA Y TECNOLOGIA

PROYECTO INGENIERIA DE GAS

Autor

Endrina Medina CI:19750938

Ciudad Ojeda, Diciembre de 2011


2/16

1.-Procesos de la gerencia de proyectos

a - Seguir un proceso de iniciacin estructurado: realizar un estudio defactibilidad financiero, tecnolgico, de recursos, impactos, estratgico y denegocio del proyecto, para prevenir inconvenientes, priorizarlo y obtener el

soporte y justificacin de negocio necesario para poder implementarlo. Durantela fase de inicio o arranque, una correcta valoracin de riesgos, asunciones,obstculos y restricciones deben ser convenientemente evaluados y el factorcrtico es realizar un adecuado proceso de valoracin de requerimientos (RM)para clarificar objetivos, necesidades y alinear las expectativas. En muchoscasos los procesos de RM pueden automatizarse pero siempre es convenientemantener sesiones y reuniones con los stakeholders para aclarar los puntosgrises. Todas las metodologas de administracin de proyectos recalcan laimportancia de una fuerte relacin con los stakeholders y su proceso deanlisis, dado que con ellos podremos lograr ms fcilmente el xito y rompermuchas barreras en los proyectos. Un error frecuente es que muchos proyectospueden tener muchos stakeholders y el team slo dialoga con aquel ms

sociable y entusiasta sin evaluar las expectativas de los otros que directa oindirectamente estn involucradas y son precisamente los que puedenponernos los palos en la rueda. Un factor comn para el xito de los proyectoes poseer la habilidad de negociar y manejar las expectativas y necesidades delos stakeholders afectados por el proyecto. La relacin con el sponsor y losstakeholders es vital y la clave es establecer una buena relacin lo queimplica ms que identificar y manejar sus expectativas, manejar una conexinemocional con la gente. El PM debe focalizarse en mejorar sus habilidadesinterpersonales, y asegurarse de que todos los stakeholders estn a bordo delproyecto manteniendo fluida comunicacin con ellos. El anlisis de losstakeholders debera permitir al PM no slo identificarlos sino categorizarlosbajo 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.

b - Planificacin del Proyecto: de acuerdo a la industria donde se realice elproyecto, la planificacin podr tomar diferentes matices. Los proyectos para eldesarrollo de software son bastante particulares, tan es as, que surgieronmetodologas propias para los mismos (Agil Development) diferentes a lastradicionales como el PMBOK. Algunos aspectos de las metodologas gilespueden ser utilizados en cualquier otro proyecto. Actualmente est de modahablar tambin de Lean Six Sigma Project Management, otra aproximacin a lagestin efectiva de proyectos. Independientemente de que se utilice unametodologa tradicional, gil o lean; una buena planificacin siempre esnecesaria. En la metodologa tradicional la planificacin es exhaustiva ycompleta, en los ciclos ms acelerados y livianos (gil o lean) la planificacinse concentra en delimitar los bordes del proyecto para crear una lista priorizadade entregables que sern liberados en fases de tipo iterativa. Planescomprensivos, realistas y bien comunicados son imprescindibles en todos losproyectos, an con cortos ciclos de vida. Involucrar no slo al team sino a losstakeholders en el desarrollo de los planes, discutir acerca de todos losobjetivos y entregables del proyecto y explicar claramente los riesgosinvolucrados son tambin factores esenciales. Como corolario final el consejo


3/16

es no embarcarse en planificaciones extensas, construir planes a corto plazo ydetallados (elaboracin progresiva segn el mismo PMBOK), e ir elaborandolos requerimientos sobre la marcha en una aproximacin de tipo iterativo.

c - Utilizar auditoras: para evaluar la salud del proyecto, deberan realizarseauditoras y reuniones de quality assurance en forma frecuente para chequear

no slo los entregables sino el estado y progreso del proyecto. Medir elprogreso real versus el costo y tiempo estimado es muy importante, al igual querealizar mediciones de calidad respecto del cumplimiento de los requerimientosy el alcance de los entregables. No podemos controlar y mucho menos mejorarsi no tenemos mtricas. Debemos desarrollar criterios estndar de medicintanto de calidad como de productividad y eficiencia, para saber no slo dndeestamos sino qu y cmo debemos mejorar. El PM debe desarrollar todas lasactividades y procesos definidos dentro del grupo de Monitoreo y Control delProyecto que involucra el control del progreso del mismo (tiempo y tareas), elcontrol del alcance (cambios) el control del rendimiento (performance), elcontrol de los costos (mtodo del valor ganado) y el control de calidad. Dedichos controles surgirn reportes y medidas correctivas o preventivas.

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

y 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.).

y Realizacin de auditoras segn procedimiento y plan definidos. Esconveniente desde el punto de vista prctico que la realizacin deauditoras sea sistemtica, y el propio director o responsable del rea aauditar transmita a sus subordinados afectados las fechas concretas enlas que estas auditoras sistemticas van a realizarse para que prestensu mayor colaboracin. Los documentos que recojan los resultados delas auditoras, es decir, respuestas, comprobaciones, resultados de


4/16

medidas y ensayos, etc., han de estar consensuados entre auditor yauditado, de tal forma que recojan la conformidad de ambos, evitndosediscusiones intiles. Se trata de auditar la efectividad de la gestin delproyecto, tanto a travs del grado de cumplimiento de los procesos,como a travs de la calidad del producto obtenido.

y Evaluacin de los resultados de la auditora. Toda auditora ha derealizarse para obtener una nota final que sirva, aunque slo seacomparativamente, para medir la evolucin y progreso del proyecto. Loque se pretende es la obtencin de una valoracin totalmente objetivapor lo que el sistema de valoracin ha de ser consensuado, y adems,experimentado durante cierto tiempo, para poder fijar las seales dealerta, ndices de ponderacin, etc.

y Redaccin de un informe y propuesta de medidas correctivas de sernecesario, con expresin de su grado de urgencia. Una vez valorada laauditora y antes de la redaccin del informe final y propuesta de lasmedidas correctoras, es conveniente la reunin con el PM afectado por

la auditora para que sea el primer informado y pueda incluso colaboraren la propuesta de medidas correctoras as como la decisin sobre laurgencia de las mismas, pues es conveniente que tanto el informe de laauditora como la propuesta de medidas correctoras, lo asuma comoalgo propio, entre otras cosas porque a veces, podr ejercer mspresin sobre la Gerencia que el propio auditor, sobre todo si alguna delas medidas propuestas corresponden o requieren inversiones.

d - Utilizacin de recursos humanos: la correcta utilizacin de las tcnicasblandas y el uso adecuado de las habilidades interpersonales son factores

crticos en el manejo de todos los proyectos. Un tema controversial que sueletraernos dolores de cabeza son 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 lecobra de acuerdo al proyecto un precio fijo o time & material (por hora deconsultora). En ambos casos se toma para la formacin del precio el costrate de los recursos que trabajarn en el proyecto, independientemente de queel recurso pertenezca o no a la organizacin ejecutante. Si pertenece a laorganizacin y trabaja ms de 40 horas a la semana, su salario ser siempre elmismo, pero a los efectos de cobro al cliente en el caso de time & materialpodramos cobrar las horas overtime, algo que, en la prctica slo se le pagaal recurso si es externo a la organizacin. En los casos de precio fijo, durante laplanificacin normalmente calculamos en la herramienta de scheduling 40horas de trabajo semanal. Si observamos que existen recursos con sobrealocacin (ms de 8 horas por semana) la tcnica ms comn a utilizar sera elresource-leveling algo que generalmente terminar por enviarnos el final delproyecto al lado oscuro de la luna. En la prctica normalmente no se hace nadadado que el recurso si es parte de la plantilla de la organizacin, trabajar esashoras extras que por lo general y debido a su rango no son pagadas en laprctica dado que recibe su sueldo mensual fijo. El problema se presenta


5/16


6/16

herramientas automticas de RM (Requirement Management) y CM(Configuration Management). Tener muy claro el procedimiento para solicitarlos cambios, el tipo de formulario, como debe ser completado y el mtodo paraaprobacin respectivo. Si el Gerente de Proyecto no ha definido bien el alcanceinicial del proyecto, ser tremendamente difcil administrar el mismo. Elpropsito de la administracin de cambios es proteger la viabilidad de la

definicin del proyecto ya definida y aprobada. Cuando se solicita formalmenteun cambio implica que dicho cambio est fuera del alcance acordado en ladefinicin del Proyecto o de los requerimientos o solicitudes detallados duranteel anlisis. Si dicho alcance es confuso, poco claro, o deja lugar ainterpretaciones, entonces el cliente dir que el cambio est dentro del alcance,y el Gerente de Proyecto encontrar difcil apegarse a un proceso formal deGestin de Alcance. En algunos proyectos es posible anticipar todas lassolicitudes y requerimientos durante el proceso de anlisis. No obstante lo cual,siempre podr existir la posibilidad y la necesidad de incorporar cambiosdurante el ciclo de vida. Estos cambios pueden ser muy necesarios para lasolucin, y pueden existir razones poderosas de negocio por las que deberanincorporarse. El Gerente de Proyecto y el equipo de trabajo, deben reconocer

el momento en que los cambios son requeridos y debern seguir un procesopredefinido de gestin del alcance. Este proceso, eventualmente, proporcionarinformacin para que el sponsor tome las decisiones pertinentes y tambin lepermitir decidir si la modificacin deber aprobarse en base al valor e impactoen el proyecto en trminos de costo y tiempo. Debe ser claro para todas laspartes que cumplir estos nuevos requerimientos con los mismos recursos de ladefinicin anterior, es prcticamente imposible.

h - Buffers: incertidumbre, probabilidades: son temas que hacen a lagestin cuantitativa de los proyectos. Primero y fundamental es necesario nomezclar (al menos sin identificar claramente) las contingencias que nostomamos en las estimaciones con la duracin puesta a cada tarea. Estacontingencia debe ser claramente identificada y manejada para evitar el efectode la famosa Ley de Parkinson. El mtodo de la Cadena Crtica coloca todasestas contingencias en un buffer compartido para todo el proyecto de usoexclusivo del PM. De no utilizar este mtodo el PMBOK nos aconseja utilizarcontingencias o buffers por las incertidumbres en las estimaciones utilizandoCPM/PERT, MonteCarlo, Varianza de la media, o simplemente un porcentajedel total de costo o tiempo adicional. El clculo del tamao del buffer debetener en cuenta muchos factores. Hablar de incertidumbre en riesgos o en lasestimaciones no es exactamente lo mismo que hablar de cul sera laprobabilidad de ocurrencia. En forma simple, al arrojar una moneda existe unaincertidumbre respecto de si saldr cara o ceca. Pero no hay incertidumbre

respecto de las probabilidades de que salga cara dado que ambas tienen un50%. Si la probabilidad de un evento se acerca ms al 100% estaremos muchoms tranquilos porque reducimos su incertidumbre, pero inevitablementeaumentaremos su rango. Por ejemplo, si tenemos una pieza mecnica que atravs de mediciones hechas durante 5 aos sabemos que puede causardaos humanos en un impacto con rango del 35% al 45% (10%) y esto no esaceptable, lo que ocurrir es que se realizarn tareas de ingeniera paramejorar dicha pieza y reducir ese impacto negativo. Supongamos que logramosarmarla de otra forma y que ahora las probabilidades de que ocurra algo malo


7/16

son del rango entre 5% y 25% (20%). Hemos reducido significativamente laprobabilidad de un accidente pero como no hay historia pasada el rango de laincertidumbre es ms alto (del 10 al 20%).

i - Subcontratar desarrollos externos (Outsourcing): muchas veces hetrabajado como prime contractor en proyectos en donde tenamos muchos

proveedores involucrados (en algunos casos, su desarrollo era ms importanteque el nuestro). En este aspecto son vlidas todas las recomendaciones delPMBOK sobre adquisiciones, adems de tener en cuenta todas lasmodalidades contractuales y de mantener el pari passu (mismas condicionesde obligaciones y responsabilidades contractuales) de las clusulas del clientecon nuestros proveedores. En este caso me referir a un tema muy corrienteen 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 mayorade las empresas hoy en da pregonan ser certificadas en CMMI. Esto esimposible dado que CMMI no es una certificacin, el SEI no certificaorganizaciones como el ISO o el ITSMF, sino que autoriza a personasdenominadas lead appraisers a conducir auditoras para determinar el grado

de madurez de la organizacin respecto del modelo. El SEI no confirma lacerteza del nivel de madurez reportado, sino que su foco es ms bien la calidadcontinua de la organizacin, que identifique en qu nivel se encuentra y querealice todos los esfuerzos necesarios para mejorar su calidad y hacer susprocesos repetibles.

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

y Cundo fue publicado su ltimo assessment? (dura 2 aos)y Copia de la documentacin donde figura qu reas son las ms fuertes y

cules con las ms dbiles.y Quin desarroll el lead assessment?y Cules son sus planes de mejora continua?y Con qu otros clientes trabaja?


8/16

Otra caracterstica asociada a la inmadurez de nuestro mercado es el error deescuchar a un gerente decir: esta tarea ya no representa un problema porquela hemos subcontratado. Esto es falso, fundamentalmente porque lainestabilidad de nuestro mercado hace que sea muy difcil desarrollar

relaciones cliente proveedores que perduren en el tiempo. Por otro lado, estainestabilidad y lo pequeo del mercado generan el problema que losproveedores en gran medida sean Pymes, y stas permanentemente deben detener una muy agresiva actitud de venta, sobre todo si son proveedores quedependen de la aparicin de proyectos en el mercado para tener trabajo yresulta muy difcil su evaluacin porque no hay una manera simple de saber elestado en que se encuentra dicho proveedor. Es posible analizar los contratosque tiene en ejecucin, pero no es posible analizar los contratos que estn a lafirma, y muchas veces la concrecin de uno, genera mejores condiciones enlas Pymes para enfrentar las negociaciones con los otros contratos, y seproduce una cascada de contratos que se firman, una cantidad decompromisos simultneos que este proveedor tiene que cumplir, y como

generalmente no cuenta con reservas de recursos humanos ni con unaplanificacin previa tiene como resultados crisis de recursos y falta decumplimiento 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 delcontratista, que tiene sus propias crisis, la que potencian a la de lossubcontratistas. Cuando bajamos de nivel, nos encontramos con empresasms pequeas, ms inestables, ms riesgosas y ms difciles de predecir, congrandes inconvenientes para tomar buenas decisiones.

j Project Manager, Lder o Facilitador: Un Gerente de Proyecto debedesarrollar diferentes roles por lo que es importante la ptima aplicacin de sushabilidades personales. Normalmente un PM debe cumplir con su rol deGerente pero adems debe tambin ser el Lder del grupo de trabajo, aspectosque tienen distintos objetivos. El lector debera conocer la importancia delproceso de Team Building y cmo los grupos van madurando a lo largo deldesarrollo del proyecto. Actualmente tambin podemos clasificar a los equiposde trabajo conforme a su capacidad tcnica y resolutiva, llegando a tenerequipos de trabajo denominados de Alto Desempeo en donde los conflictoslos resuelven entre ellos, toman decisiones propias y pueden autogestionarse.En estos casos el rol del PM ms importante es el de Facilitador donde lo queprima es dejar trabajar con libertad y preocuparse ms en eliminar losproblemas 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 alSponsor activamente involucrado pero se aseguran que no interfiera en eltrabajo; documentan al nivel necesario. Estamos hablando de gente de altaconfianza y estima que demuestran carisma, empata, respeto y sensibilidadpor el grupo de trabajo. Podemos decir entonces que otro factor clave en lagestin de los proyectos es colocarse el sombrero adecuado teniendo encuenta el tipo de proyecto, el team de trabajo o las circunstancias especialesque estemos controlando.


9/16

k Project Management Estratgico: el tema se basa en asegurarse de quetodos los proyectos estn estratgicamente alineados y fueron previamenteanalizados por la PMO o un proceso de PPM. Se debe definir un criterio contrael cual todos los proyectos pueden ser priorizados que incluya el impacto en lasestrategias corporativas y los clientes, y confeccionar una lista de todos losproyectos, sus metas y objetivos estratgicos. Despus, tratar de identificar elcriterio de xito de los mismos y determinar el impacto esperado que cadaproyecto tendr en la organizacin y sus clientes. Asignar un rango para cadaproyecto cuantitativamente y determinar su nivel de prioridad. Alinear losproyectos con los planes estratgicos corporativos y departamentales, yejemplificar cmo la ejecucin exitosa de cada proyecto apoyar el planestratgico de la corporacin o del departamento. En ciertos casos no quedaotra salida que cancelar los proyectos que son de baja prioridad o que no estnligados a la estrategia corporativa o departamental. Qu se puede hacer paraimplementar las mejores prcticas de Project Management Estratgico?: laretencin del conocimiento es uno de los mayores beneficios para lasorganizaciones ya que contribuye al aprendizaje continuo y ayuda a evitar larepeticin de errores. Con objeto de retener el conocimiento sobre laimplementacin efectiva de proyectos y que puedan ser pasados comolecciones aprendidas hacia equipos de proyectos a futuro, la PMO deberatener 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 sucedidurante el transcurso del proyecto y qu puede aprender el equipo y laorganizacin de lo sucedido. El sponsor del proyecto, el responsable delproyecto y el equipo de trabajo debern estar presentes as como cualquierrecurso exterior o stakeholders quienes quisieran contribuir con ideas. Elresultado final de esta reunin de cierre del proyecto ser la creacin de undocumento formal de lecciones aprendidas para ser llevadas a proyectosfuturos, a los gerentes y a sus equipos de trabajo. El establecimiento demediciones de proyectos exitosos desde el punto de vista estratgico tambin


10/16

ayudar a proveer a la alta direccin de informacin relevante y necesaria paratomar decisiones que afecten el proyecto. Por ejemplo, la presentacinestratgica de las medidas del xito del proyecto puede convencer a la altadireccin de re-priorizar proyectos o de re-asignar recursos. Las medidas delxito del proyecto proveern a la PMO de la informacin necesaria para quevenda el impacto de la efectividad al nivel gerencial. Los criterios para el xito

en la medicin de los proyectos estratgicos deben incluir:

y La utilizacin de un criterio de calidad especificado.

y La habilidad para enfrentar cambios en los requerimientos.

y El nmero de recursos usados actualmente contra el nmero derecursos anticipados originalmente.

y La habilidad del proyecto para alcanzar sus objetivos y entregablesespecficos.

y Las encuestas de satisfaccin de clientes que indican su conformismocon el producto o la entrega del servicio del proyecto.

y La puesta en produccin o lanzamiento exitoso y sin problemas.

y Mediciones financieras adecuadas y dentro de los lmites.

Finalmente para las organizaciones que estn considerando en definir cules la mejor metodologa para administrar sus proyectos, o cmo adaptar la

metodologa del PMBOK a sus propias necesidades, la recomendacin esconsiderar un buen programa de entrenamiento de sus PM y considerar suposible certificacin, que ofrezca una revisin de la metodologa y las reasclaves para su organizacin: costos, tiempos, riesgos, calidad, junto conuna visin ms amplia, crtica y realista. Otra alternativa es contratar a unaorganizacin con consultores especializados y certificados PMP para quecolaboren en la implementacin de los proyectos y realicen la transferenciade conocimientos y prcticas necesarias.


11/16

1.1 Interacciones de los grupos

2 Los Grupos de Procesos de Direccin de Proyectos estn relacionados porlos resultados que producen. La salida de un proceso, por lo general, seconvierte en una entrada a otro proceso o es un producto entregable delproyecto. El Grupo de Procesos de Planificacin proporciona al Grupo de

Procesos de Ejecucin un plan de gestin del proyecto documentado y unenunciado del alcance del proyecto, y a menudo actualiza el plan degestin del proyecto a medida que avanza el proyecto. Adems, losGrupos de Procesos pocas veces son eventos discretos o que ocurren unanica vez; son actividades superpuestas que se producen con distintosniveles de intensidad a lo largo del proyecto. La Figura 3-11 ilustra cmointeractan los Grupos de Procesos y el nivel de superposicin en distintosmomentos dentro de un proyecto. Si el proyecto se divide en fases, losGrupos de Procesos interactan dentro de una fase del proyecto y tambinpueden entrecruzarse entre las fases del proyecto.

3

Figura 3-11. Los Grupos de Procesos interactan en unproyecto. [PMBOK]

3 Entre los Grupos de Procesos y sus procesos, las salidas de los procesos serelacionan y tienen un impacto sobre los otros Grupos de Procesos. Porejemplo, el cierre de una fase de diseo requiere la aceptacin por parte delcliente del documento de diseo. Entonces, el documento de diseo define ladescripcin del producto para el siguiente Grupo de Procesos de Ejecucin.

Cuando un proyecto est dividido en fases, los Grupos de Procesosnormalmente se repiten dentro de cada fase durante la vida del proyecto paraposibilitar su conclusin efectiva. Los Grupos de Procesos y sus relaciones seilustran en la Figura 3-1


12/16

Figura 3-12. Tringulo de Grupo de Procesos de Direccin deProyectos.[PMBOK]

4 Sin embargo, as como no todos los procesos sern necesarios en todos losproyectos, no todas las interacciones sern aplicables a todos los proyectos ofases del proyecto Por ejemplo: En los proyectos que dependen de recursos nicos (por ejemplo, eldesarrollo de software comercial y productos biofarmacuticos), pueden

establecerse roles y responsabilidades antes de la definicin del alcance,dado que lo que se puede hacer depende de quin est disponible parahacerlo. Algunas entradas del proceso se definen previamente como restricciones.Por ejemplo, la direccin puede establecer una fecha de conclusin objetivoen lugar de dejar que esa fecha sea determinada por el proceso deplanificacin. Una fecha de conclusin impuesta, a menudo, requerirestablecer un cronograma hacia atrs a partir de esa fecha,y puede aumentarel riesgo del proyecto, sumar costes,comprometer la calidad o, en casosextremos, exigir un cambio significativo en el alcance

2. Areas de conocimiento de la gerencia de proyectos


13/16

1. Gerencia De La Integracin Del Proyecto

Un subconjunto de la gerencia de proyecto que incluye los procesos requeridospara asegurarse de que los varios elementos del proyecto estn coordinadoscorrectamente. Esta rea de conocimiento consta de algunos aspectos como loson:

Desarrollo del plan de proyecto: Integrar y coordinar todo el proyecto, planeary crear un documento constante, coherente.

Ejecucin del plan del proyecto: realizar el plan del proyecto, realizando lasactividades incluye en este.

Control integrado de cambios: cambios que coordinan a travs del proyectoentero.

2. Gerencia Del Alcance Del Proyecto

Consiste en un subconjunto de la gerencia de proyectos que incluye losprocesos requeridos para asegurarse de que el proyecto incluya todo el trabajorequerido y solamente trabajo requerido para terminar el proyecto con xito.Esta rea del conocimiento incluye aspectos como:

Iniciacin: autorizar el proyecto o la fase

Planeamiento del alcance: desarrollar una declaracin escrita del alcancecomo la base para las decisiones futuras del proyecto.

Definicin del alcance: subdividir los deliverables principales del proyecto encomponentes ms pequeos, ms manejables.

Verificacin del alcance: formalizacin de la aceptacin del alcance delproyecto.

Control del cambio del alcance: cambios que controlan al alcance del proyecto

3. Gerencia De Tiempo Del Proyecto

Un subconjunto de la gerencia de proyecto que incluye los procesos requeridospara asegurar la terminacin oportuna del proyecto. Esta rea del conocimientoincluye aspectos como:

Definicin de la actividad: identificando las actividades especficas que sedeben realizar para producir las varias fases del proyecto.

Actividad que ordena: identificando y documentacin de dependencias de lainteractividad.

Duracin que estima: estimando el nmero de los perodos del trabajo quesern necesarios terminar actividades individuales.


14/16

Desarrollo del horario: analizar secuencias de la actividad, duraciones de laactividad, y requisitos de recurso de crear el horario del proyecto.

Control de la actividad del horario: cambios que controlan al horario delproyecto.

4. Gerencia Del Costo Del Proyecto

Un subconjunto de la gerencia de proyecto que incluye los procesos requeridospara asegurarse de que el proyecto est terminado dentro del presupuestoaprobado. Consiste en:

Planeamiento del recurso: determinando qu recursos (gente, equipo,materiales) y qu cantidades de cada uno se deben utilizar para realizaractividades del proyecto.

Costo estimado: desarrollar una aproximacin (estimacin) del coste de los

recursos necesit terminar actividades del proyecto.

Costo del presupuesto: asignacin de la valoracin de costos total a lasactividades individuales del trabajo.

Control de costo: cambios que controlan al presupuesto de proyecto

5. Gerencia De La Calidad Del Proyecto

Un subconjunto de la gerencia de proyecto que incluye los procesos requeridospara asegurarse de que el proyecto satisfaga las necesidades para las cualesfue emprendido. Consiste en:

Planeamiento de la calidad: identificando que los estndares de calidad sonrelevantes al proyecto y a determinar cmo satisfacerlos.

Garanta de calidad: funcionamiento total de evaluacin del proyecto sobreuna base regular para proporcionar confianza que el proyecto satisfaga losestndares de calidad relevantes.

Control de calidad: la supervisin de proyecto especfico resulta paradeterminarse si se conforman con estndares e identificar relevantes de calidadmaneras de eliminar causas del funcionamiento insatisfactorio

6. Gerencia De Recurso Humano Del Proyecto

Un subconjunto de la gerencia de proyecto que incluye los procesos requeridospara hacer el uso ms eficaz de la gente implicada con el proyecto. Esta reacomprende los aspectos siguientes:

Planeamiento organizacional: identificando, documentando, y asignandopapeles del proyecto, responsabilidades, y relaciones de divulgacin.


15/16

Adquisicin del personal: conseguir los recursos humanos necesarios paratrabajar en el proyecto.

Desarrollo de la organizacin del equipo: habilidades del individuo que seconvierten y del grupo para realzar funcionamiento del proyecto.

7. Gerencia De Comunicaciones Del Proyecto

Un subconjunto de la gerencia de proyecto que incluye los procesos requeridospara asegurar la generacin oportuna y apropiada, la coleccin, la difusin, elalmacenaje, y la ltima disposicin de la informacin del proyecto. En esta reaexisten aspectos importantes como

Planeamiento de comunicaciones: determinacin de la informacin y de lasnecesidades de comunicaciones de los tenedores de apuestas: quin necesitaqu informacin, cuando l la necesitar, y cmo les ser dada.

Distribucin de la informacin: haciendo a la informacin necesaria, disponiblepara proyectarla a tenedores de apuestas de una manera oportuna.

Funcionamiento que reportes: recogiendo y diseminacin de la informacindel funcionamiento. Esto incluye el pronstico, la divulgacin del estado,medida del progreso de proyecto.

Cierres administrativos: generando, recolectando, y diseminando lainformacin para formalizar la terminacin de la fase o del proyecto.

8. Gerencia De Riesgos Del PROYECTO

La gerencia de riesgo es el proceso sistemtico de identificar, de analizar y deresponder al riesgo del proyecto. Incluye la maximizacin la probabilidad y lasconsecuencias de acontecimientos positivos y de reducir al mnimo de laprobabilidad y las consecuencias de acontecimientos adversos de proyectarobjetivos. En estas reas se enfocan aspectos como:

Planeamiento de la gerencia de riesgo: decidiendo cmo acercar y planear alas actividades de la gerencia de riesgo para un proyecto.

Identificacin del riesgo: determinndose qu riesgos pudieron afectar elproyecto y la documentacin de sus caractersticas.

Anlisis cualitativo del riesgo: la ejecucin de un anlisis cualitativo de riesgosy las condiciones para dar la prioridad afecta los objetivos del proyecto.

Anlisis cuantitativo del riesgo: midiendo la probabilidad y las consecuenciasde riesgos y de estimar sus implicaciones para los objetives del proyecto.

Planeamiento de la respuesta del riesgo: procedimientos y tcnicas que seconvierten para realzar oportunidades y para reducir amenazas del riesgo a los


16/16

objetives del proyecto.

Riesgo que se supervisa y se controlan: supervisando riesgos residuales,identificando los nuevos riesgos que ejecutan planes de la reduccin del riesgo,y la evaluacin de su eficacia a travs del ciclo vital del proyecto.

9. Gerencia De Consecucin Del Proyecto

Un subconjunto de la gerencia de proyecto que incluye los procesos requeridospara adquirir mercancas y los servicios para lograr alcance del exterior de laorganizacin de ejecucin. Consiste en:

Planeamiento de la consecucin: determinacin qu procurar y cuando.

Planeamiento de la solicitacin: documentando requisitos del producto eidentificar fuentes potenciales.

Solicitacin: citas, ofertas, ofertas como apropiado.

Eleccin de la fuente: el elegir entre de vendedores potenciales

Administracin del contrato: manejo de la relacin con el vendedor

Liquidacin del contrato: la terminacin y el establecimiento del contrato,incluyendo la resolucin de cualesquiera abren artculos.

Documents

1gerencia de proyectos