Xestión de proxectos

A Administración de Proxectos, ou xestión de proxectos é a aplicación de coñecementos, habilidades e técnicas na elaboración de actividades relacionadas para atinxir un conxunto de obxectivos predefinidos. O coñecemento e as prácticas da xestión de proxectos quedan mellor descritos en termos dos seus procesos compoñentes.
Eses procesos poden clasificarse en cinco grupos de proceso (arranque, planificación, execución, control e peche) e nove áreas de coñecemento: xestión de integración de proxectos, xestión de alcance de proxectos, xestión de tempo de proxectos, xestión de custo de proxectos, xestión de calidade de proxectos, xestión de recursos humanos de proxectos, xestión de comunicacións de proxectos, xestión de riscos de proxectos e xestión de adquisicións de proxectos.
Na súa forma máis simple, a xestión de proxectos é a disciplina de manter os riscos de fracaso nun nivel tan baixo como sexa necesario durante o ciclo de vida do proxecto. O risco de fracaso aumenta de acordo coa presenza de incerteza durante todas as etapas do proxecto.
Un punto de vista alternativo di que xestión de proxectos é a disciplina de definir e alcanzar obxectivos ao mesmo tempo en que se optimiza o uso de recursos (tempo, diñeiro, persoas, espazo etc).
A xestión de proxectos é frecuentemente a responsabilidade dun individuo titulado xerente ou xestor de proxectos. Idealmente, ese individuo apenas participa directamente nas actividades que producen o resultado final. Ao contrario, o xerente de proxecto traballa para manter o progreso e a interacción mutua dos diversos participantes do proxecto, para reducir o risco de fracaso do proxecto. Historia da xestión de proxectos
Como unha disciplina, a xestión de proxectos foi desenvolvida de diversos campos de aplicación diferentes, incluíndo a construción, a enxeñaría mecánica, proxectos militares etc. . Nos Estados Unidos, o ‘pai’ da xestión de proxecto é Henry Gantt, chamado o pai de técnicas da planificación e do control, que se coñece polo uso do gráfico de ‘barra’ como unha ferramenta de xestión do proxecto, asociado ás teorías de Frederick Winslow Taylor da administración científica, e para o seu estudo do traballo e da xestión do edificio do navío da mariña. O seu traballo é o precursor a moitas ferramentas de xestión modernas do proxecto, tales como a WBS (work breakdown structure) ou EAP (estrutura analítica do proxecto).
Os anos 50 marcan o comezo da era moderna da xestión de proxectos. Outra vez, nos Estados Unidos, antes dos anos 50, os proxectos controlábanse basicamente utilizando os gráficos de Gantt, técnicas informais e ferramentas. Nese tempo, dous modelos programando do proxecto matemático foron desenvolvidos: (1) de 'Program Evaluation and Review Technique' ou o PERT, desenvolvido como a parte programa do mísil do submarino Polaris da mariña dos Estados Unidos' (conxuntamente con Lockheed Corporation); e o (2) 'Critical Path Method' (CPM) desenvolvido en conxunto por DuPont Corporation e Remington Rand Corporation para proxectos da mantemento de plantas. Estas técnicas matemáticas espalláronse axiña en moitas empresas.
En 1969, o Project Management Institute (PMI) foi dando forma para servir ao interese da industria da xestión de proxectos. A premisa de PMI é que as ferramentas e as técnicas da xestión de proxecto son terra común desde a aplicación nos proxectos da industria do software á industria de construción. En 1981, os directores do PMI autorizaron o desenvolvemento do que se transformou nunha guía de proxectos o 'Project Management Body of Knowledge', contendo os padróns e as liñas mestras das prácticas que se usan extensamente na profesión. O xerente de proxecto
Un proxecto desenvólvese polo profesional denominado ”xerente de Proxecto”. Este profesional raramente participa das actividades directas do proxecto que producen os resultados. A súa función é “xestionar” a execución do proxecto e a través das variábeis (calidade, custo, prazo e alcance) verificar os seus desvíos. Desta forma, o seu obxectivo xeral é minimizar os fallos inherentes aos diversos procesos.
Un xerente de proxecto ten que determinar e executar as necesidades do cliente, baseado nos seus propios coñecementos. A habilidade de adaptarse aos diversos procedementos pode proporcionarlle unha mellor xestión das variábeis e desta forma unha maior satisfacción do cliente.
No campo, un xerente de proxecto exitoso debe poder imaxinar o proxecto enteiro do seu comezo ao seu termo e desta forma asegurar que esta visión se realice.
Calquera tipo de produto ou servizo—edificios, vehículos, electrónica, software de computador, servizos financeiros etc. -- pode ter a súa execución supervisada por un xerente de proxecto e as súas operacións por un xerente de produto. Enfoque
Na industria de informática, xeralmente hai dous tipos de enfoques comunmente utilizados na xestión de proxectos. Os enfoques de tipo "tradicional" identifican unha secuencia de pasos a seren completados. Eses enfoques contrastan co enfoque coñecido como desenvolvemento áxil de software, no que o proxecto vese como un conxunto de pequenas tarefas, no canto dun proceso completo. O obxectivo deste enfoque é reducir ao mínimo posíbel o overhead. Ese enfoque é bastante controverso, especialmente en proxectos moi complexos. Mesmo así, ten conquistado adeptos en números crecentes.
Nas últimas décadas, emerxeron unha serie de enfoques na industria en xeral. De entre eses enfoques destaca o enfoque do PMBOK, que se converteu nun padrón de facto en diversas industrias.
Enfoque tradicional
No enfoque tradicional, distinguimos cinco grupos de procesos no desenvolvemento dun proxecto: Arranque ou Iniciación
Planificación
Execución
Monitorización e Control
Peche
Non todos os proxectos van seguir todas estas etapas, xa que poden pecharse antes da súa conclusión. Algúns proxectos talvez non teñan planificación ou monitorización. Algúns proxectos pasarán polos etapas 2, 3 e 4 múltiplas veces.
O proxecto ou procura satisfacción dunha necesidade ou oportunidade, definida no texto enriba como fase inicial na cal existen moitas áreas e/ou persoas involucradas.
En xeral sempre existe máis dunha solución ou alternativas para atender ás mesmas necesidades. A técnica usada para definir a solución final pasa polo desenvolvemento de alternativas extremas. A primeira, de baixo custo, que atende as necesidades mínimas para ser operativa. A segunda tenta atender a maior parte das as exixencias das diversas áreas envolvidas dentro do alcance do proxecto, o que resulta nun custo moito maior e pouco competitivo.
A partir de ambas as alternativas é desenvolvida unha solución intermedia entre as mesmas, que atende a unha boa parte das exixencias cun custo competitivo.
Moitos sectores utilizan variacións destas etapas. Por exemplo, na construción civil, os proxectos tipicamente constan de etapas como Pre-planificación para deseño Conceptual, deseño esquemático, deseño de desenvolvemento, construción de deseños (ou documentos de contrato), e administración de construción. Aínda que os nomes difiren en cada industria, as etapas reais normalmente seguen os pasos comúns á resolución de problemas (problem solving): definir o problema, sopesar opcións, escoller un camiño, posta en funcionamento e avaliación.
A xestión de proxectos tenta adquirir control sobre tres variábeis: tempo
custo
alcance
Algunhas literaturas definen como catro variábeis, sendo calidade a cuarta variábel; con todo a calidade é unha das principais compoñentes do alcance.
Estas variábeis poden darse por clientes externos ou internos. O(s) valor(es) das variábeis remanentes está(n) a cargo do xerente do proxecto, idealmente baseado en sólidas técnicas de estimación. Os resultados finais deben acordarse nun proceso de negociación entre a xestión do proxecto e o cliente. Xeralmente, os valores en termos de tempo, custo, calidade e alcance defínense por contrato.
Para manter o control sobre o proxecto do inicio ao fin, un xerente de proxectos utiliza varias técnicas, de entre as cales se destacan: Planificación de proxecto
Análise de valor agregado
Xestión de riscos de proxecto
Cronograma
Melloría de proceso
Desenvolvemento áxil de software
O desenvolvemento áxil de software agrupa unha serie de metodoloxías de xestión de proxectos de software que parten de que o software é un tema difícil de acoutar desde o principio, suxeito a moitos cambios e evolucións, e polo tanto que necesita de modificacións ao longo do propio proceso de desenvolvemento.
Os métodos áxiles, ou lixeiras, diferéncianse doutras metodoloxías máis "pesadas" (como por exemplo, o modelo de desenvolvemento en fervenza) na énfase que dan a valores e principios, en vez de aos procesos. Nos proxectos áxiles, o desenvolvemento organízase en ciclos de duración breve (unhas semanas), e na fin de cada ciclo hai unha reavaliación das prioridades do proxecto. Esta é unha característica común ás metodoloxías de desenvolvemento iterativas, e á maioría das teorías modernas de xestión de proxectos. As variábeis
Algúns proxectos, necesitan seren executados e entregados baixo determinadas variábeis. As variábeis principais, tamén denominadas tradicionais, son o alcance, o tempo e o custo. Isto coñécese tamén como ao triángulo da xestión de proxecto, onde cada lado representa unha variábel. Un lado do triángulo non pode mudarse sen impactar no outro. Como comentado anteriormente, algúns profesionais entenden que a variábel ´calidade’ esta separada do alcance, e definen esta como sendo unha cuarta variábel.
A restrición do tempo influencia o proxecto no seu termo. A restrición de custo informa o valor monetario incluído no orzamento dispoñíbel para o proxecto. Finalmente a restrición do alcance determina o que se debe facer para que o produto final teña a funcionalidade requirida. Estas tres variábeis están frecuentemente competindo: se aumenta o alcance implica tipicamente que o tempo aumenta e o custo aumenta, unha restrición apertada de tempo podería significar uns custos aumentados e un alcance reducido, e un orzamento apertado podería significar o tempo aumentado e o alcance reducido.
A disciplina da xestión de proxecto trata de fornecer as ferramentas e as técnicas que permiten o equipo de proxecto (non só ao xerente de proxecto) organizar o seu traballo para se atopar con estas variábeis.
Tempo
O tempo requirido para terminar o produto do proxecto, manéxase normalmente cando se pretende baixar o tempo para execución de cada tarefa que contribúe directamente á conclusión de cada compoñente. Ao executar tarefas usando a xestión de proxecto, é importante partir o traballo en diversas partes menores de modo que sexa fácil definirmos as condicións de criticidade e de folga.
Custo
O custo de desenvolver un proxecto depende de diversas condicións iniciais tales como: custos laborais, custos materiais, xestión de risco, planta (edificios, máquinas etc. ), equipamento, e beneficio.
Alcance
Son as exixencias especificadas para o produto ou resultado final, ou sexa, o que se pretende realizar. Un compoñente principal do alcance é a calidade do produto final. Project Management Body of Knowledge
O enfoque do PMBOK non se restrinxe ao desenvolvemento de sistemas, sendo utilizada en moitas industrias (notablemente nas industrias ligadas á construción civil). De acordo con esta enfoque, a xestión de proxectos aborda as seguintes áreas de coñecemento: Xestión de integración de proxectos
Xestión de alcance de proxectos
Xestión de tempo de proxectos
Xestión de custo de proxectos
Xestión de calidade de proxectos
Xestión de recursos humanos de proxectos
Xestión de comunicacións de proxectos
Xestión de riscos de proxectos
Xestión de adquisicións de proxectos Padróns de xestión de proxectos
Ao longo do tempo, houbo diversas tentativas para desenvolver padróns internacionais de xestión de proxectos. De entre elas, destacan: Project Management Body of Knowledge (PMBOK), un conxunto de coñecementos xestionado pola organización Project Management Institute (PMI). Tense tornado un padrón de feito en diversas industrias, como a da Construción Civil e en diversos sectores da Industria de Software.
ISO 10006: 1997, Quality management - Guidelines to quality in project management
PRINCE2 (Projects IN a Controlled Environment)