proyectos. La gestión de Conceptos básicosuoc.gitlab.io/2015/gestion...

La gestión deproyectos.Conceptosbásicos José Ramón Rodríguez PID_00153562

© FUOC • PID_00153562 La gestión de proyectos. Conceptos básicos

Ninguna parte de esta publicación, incluido el diseño general y la cubierta, puede ser copiada,reproducida, almacenada o transmitida de ninguna forma, ni por ningún medio, sea éste eléctrico,químico, mecánico, óptico, grabación, fotocopia, o cualquier otro, sin la previa autorización escritade los titulares del copyright.

© FUOC • PID_00153562 La gestión de proyectos. Conceptos básicos

Índice

Introducción............................................................................................... 5

Objetivos....................................................................................................... 7

1. Qué es un proyecto............................................................................ 9

1.1. El proyecto y las demás cosas ..................................................... 10

1.2. Los proyectos TIC ....................................................................... 11

1.3. Proyectos TIC y productos TIC ................................................... 13

2. Dimensiones de un proyecto........................................................... 15

2.1. Definiciones ................................................................................. 15

2.2. Ámbitos de conocimiento experto en la gestión de proyectos ... 17

3. Ciclo de vida de un proyecto.......................................................... 20

3.1. Iniciación ..................................................................................... 21

3.2. Planificación ................................................................................ 22

3.3. Ejecución ..................................................................................... 22

3.4. Seguimiento y control ................................................................ 23

3.5. Cierre ........................................................................................... 23

4. El ciclo de gestión de proyecto comparado con el ciclo de

producción........................................................................................... 25

5. Factores críticos de éxito en un proyecto.................................... 28

6. La cultura de proyecto dentro de las organizaciones: la

gestión por proyectos como modelo organizativo.................... 31

7. Resumen................................................................................................ 34

© FUOC • PID_00153562 5 La gestión de proyectos. Conceptos básicos

Introducción

La mayoría de los textos de gestión de proyectos, y muchos manuales genera-

les de gestión de las TIC, comienzan por los fracasos, fallos y errores en los

proyectos TIC. Las conversaciones, anécdotas y chistes de los profesionales de

las TIC, también. Existen webs bastante divertidas dedicadas a ello. Empírica-

mente, se dice que más del 50% de los proyectos informáticos no responden

a los objetivos que tenían planteados o han tenido desviaciones significativas

de tiempo o de coste. Según algunos autores, esta cifra llega al 70%.

El Standish Group realiza estudios periódicos sobre la salud de la gestión de

proyectos en todo el mundo y, aunque es perceptible un cierto proceso de me-

jora, todavía un porcentaje significativo de proyectos son cancelados y la ma-

yoría presentan desviaciones de tiempo y de coste que para el profano pueden

parecer incomprensibles e insoportables.

En efecto, gestionar con éxito proyectos en general, y los que envuelven tec-

nologías de la información y comunicaciones (TIC) en particular, es cada vez

más difícil porque supone mayores niveles de exigencia (en términos de tiem-

po, coste y calidad), pero también de riesgo y complejidad, derivados del ta-

maño, la multidisciplinariedad y el cambio tecnológico. Al mismo tiempo, re-

quiere no sólo habilidades técnicas, sino de gestión de las personas.

La gestión de proyectos es la disciplina de conocimiento y experiencia

que permite planificar, organizar y gestionar proyectos. Esto quiere decir

sobre todo dos cosas:

• Asegurar que los proyectos se completan satisfactoriamente y que

se consiguen sus productos y resultados últimos.

• Hacerlo de manera que se pueda predecir y controlar su evolución,

responder a los cambios y explicarlo satisfactoriamente al cliente y

al equipo de trabajo.

En la práctica, cada vez más la gestión de proyectos (project management) apa-

rece como una disciplina, actividad y hasta una profesión separada dentro de

la gestión de empresas y de las organizaciones en general. Por otro lado, los

buenos gestores de proyectos son profesionales muy apreciados. Por último,

las empresas están adoptando la gestión de proyectos como una forma orga-

nizativa para muchas funciones y procesos de negocio y para el abordaje de

proyectos de cambio de cualquier clase.


La profesión de gestor de proyectos

• El responsable de proyecto es un profesional cuya especialización consiste en for-mar, organizar y dirigir el equipo de trabajo.

• Trabaja en contacto con mucha gente (el equipo propio, el cliente, otros provee-dores, partes interesadas en el proyecto, etc.).

• Su única misión es que el proyecto se haga en los plazos y términos establecidos.

• Para esto, debe coordinar y supervisar los trabajos (técnica y económicamente) yvigilar y actuar sobre el entorno en el que se realiza el proyecto.

• El responsable de proyectos está sometido a una fuerte presión, pero a la vez esun trabajo apasionante, lleno de retos y variado.

• En su perfil, es importante la capacidad analítica y de gestión, ser creativo, activoy personalmente maduro. En algunos países existen escuelas o institutos, sistemasde organización y colegios profesionales de gestores de proyectos.

• No existen estudios de esta profesión. Muchos conocimientos están incluidosen algunas carreras técnicas (Ingeniería, Arquitectura, Informática, etc.), pero enrealidad la puede realizar cualquier profesional.

• Para la formación de gestión de proyectos, aparte de habilidades y metodologías,la formación en el trabajo y en la práctica es lo más importante y, de este modo,asumir responsabilidades progresivas en proyectos y con la adecuada supervisióny retroalimentación.

Fuente: Varios autores (2002). Descubre las profesiones actuales. Barcelona: Planeta

Desde esta cita del año 2002, muchas cosas han cambiado en España y en to-

do el mundo. La profesión comienza a estar reconocida, existen estudios es-

pecíficos, asociaciones profesionales y sistemas de certificación, y las empresas

valoran y exigen profesionales con esta formación, habilidades y experiencia.

Todas éstas son razones como para que los conocimientos en gestión de pro-

yectos tengan un papel cada vez más importante entre los profesionales de las

TIC y en los planes de estudios.

Ved también

En este material hablaremos degestión de proyectos en sen-tido genérico como sinónimode dirección de proyectos. Tam-bién esto permite al alumnodistinguir este material de lade segundo ciclo o máster deDirección o gestión avanzadade proyectos.


Objetivos

En este módulo, pretendemos proporcionar una visión general de un proyecto

y de la gestión de proyectos como metodología y disciplina:

1. Entender qué es un proyecto, sus características y componentes, frente al

resto de las operaciones ordinarias de la empresa.

2. Mostrar las peculiaridades de un proyecto TIC frente a otras clases de pro-

yectos en las organizaciones humanas y las empresas.

3. Establecer y definir las dimensiones principales de un proyecto: los obje-

tivos o requisitos, los plazos de ejecución y los recursos y costes asociados.

4. Mostrar los temas característicos de la gestión de proyectos en la actuali-

dad: la gestión de la calidad, la gestión del alcance y limitaciones del pro-

yecto y la gestión de los riesgos.

5. Establecer los factores que son críticos para el éxito o el fracaso de un pro-

yecto.

6. Introducir otros aspectos que se desarrollarán en los capítulos siguientes,

como son: el ciclo de vida o etapas principales del proyecto; los aspectos

de organización, liderazgo y gestión de los recursos humanos del proyecto,

y los aspectos de comunicación y relaciones internas y externas al equipo

de proyecto.


1. Qué es un proyecto

En sentido amplio, un proyecto es un conjunto o una secuencia de ac-

tividades que desarrolla durante un tiempo un equipo de personas para

obtener un resultado único.

Para entenderlo mejor:

• Un proyecto es un proceso; es decir, un conjunto de actividades interrela-

cionadas, en las que se transforman un conjunto de recursos (inputs) en

un conjunto de resultados (outputs), que tienen un sentido para alguien

(un cliente).

• Un proyecto tiene un objetivo. Normalmente, el resultado u objetivo es

también un proceso, o la transformación de uno que ya existe, sea éste el

cálculo de la nómina, los resultados de las olimpiadas o la producción de

una nueva lavadora.

• Tiene una duración, un inicio y un final. La temporalidad es quizá el ele-

mento clave y diferencial de un proyecto frente a otra clase de proceso.

• Es único y diferente. Frente a las operaciones repetitivas, propias de la ma-

yoría de los procesos empresariales, cada proyecto es único e irrepetible.

• Es multidisciplinario, involucra recursos y habilidades de diferentes partes

de la organización.

• Tiene recursos limitados y, por lo tanto, una serie de costes, directos, indi-

rectos y de oportunidad para la organización.

• Un proyecto es un encargo específico, dirigido y ad hoc, que encarga una

organización a un grupo interno o externo de personas, que se configura

para su ejecución.

Muchas actividades de la vida diaria (organizar una excursión, construir una

cabaña, realizar una mudanza, estudiar una carrera, etc.) son en realidad pro-

yectos. Y cada vez más, las empresas excelentes organizan sus procesos y fun-

ciones en forma de proyectos.


1.1. El proyecto y las demás cosas

El Project management body of knowledge (PMBOK), que será para nosotros la

referencia metodológica más importante a lo largo de este material, como lo

es actualmente para la profesión, define proyecto de la siguiente manera:

Un proyecto es un empeño temporal llevado a cabo para crear un pro-

ducto, servicio o resultado único.

Estas tres características (la temporalidad, la elaboración progresiva, y la crea-

ción de un resultado que es único, ver figura 1) serían lo más característico de

un proyecto, y las tres juntas distinguirían el modo proyecto de las demás ac-

tividades o procesos que constituyen las operaciones ordinarias de la empresa:

• Las operaciones son repetitivas y continuas, mientras que los proyectos

son temporales y únicos.

• Las operaciones son permanentes y sirven para mantener el negocio,

mientras que los proyectos son temporales y acaban cuando se ha obteni-

do el producto.

• Las operaciones, normalmente, ocupan una parte de la empresa de forma

especializada, mientras que los proyectos se constituyen por un equipo ad

hoc, del que pueden formar parte miembros de cualquier departamento así

como personal externo.

Figura 1. Características únicas del proyecto

El Project management body of knowledge (PMBOK)

El PMBOK (que traduciríamos como 'cuerpo de conocimiento de gestión de proyec-tos') es un estándar de gestión de proyectos reconocido internacionalmente y quese aplica en toda clase de sectores (construcción, ingeniería, automoción...) y en lasindustrias TIC. Estos estándares se integran con otros estándares de calidad o de pro-ducción, como ISO o CMM (el modelo de madurez en la producción de software delSoftware Engineering Institute). Se publica, mantiene y actualiza desde 1987 por elProject Management Institute, que a su vez otorga formación y certificaciones pro-

PMBOK

En español, cuerpo�de�cono-cimiento�de�gestión�de�pro-yectos.


fesionales en todo el mundo (la certificación PMP es la más reconocida y habitualy empieza a ser exigida para los jefes de proyecto en muchas industrias y países). Re-cientemente (diciembre de 2008) se ha lanzado la 4.ª edición, que es la que utilizare-mos, en general, a lo largo de este material.

Como su nombre indica, el PMBOK no es una colección normativa o prescriptiva deestándares académicos, sino un marco conceptual y una colección de lo que los pro-fesionales consideran "buenas prácticas generalmente aceptadas en gestión de pro-yectos" (de igual modo que los médicos, los abogados o los contables disponen decódigos de buenas prácticas en sus profesiones). Es una guía de buenas prácticas, queel profesional experto necesita reflexionar y adaptar a cada situación, a cada proyectoconcreto.

El PMBOK (4.ª edición, 2008) se estructura en cinco grupos básicos de procesos (quetienden a coincidir con las etapas del ciclo de vida básico de un proyecto), nueve áreaso ámbitos de conocimiento (temas o grupos de temas que necesitan manejarse en unproyecto) y cuarenta y dos procesos que ocurren en la intersección de los grupos deprocesos. Cada proceso se compone de unos inputs (documentos, planes, resultadosde una fase anterior...), unas herramientas y técnicas (que se aplican y trabajan sobrelos inputs) y unos outputs (productos del trabajo realizado en cada proceso y que sona su vez documentos, planes o resultados parciales). En el módulo "Componentes dela gestión de proyectos: las áreas de conocimiento" de este material, explicaremos deuna forma más detallada el contenido y funcionamiento de esta guía.

El PMBOK no dispone de una adaptación sectorial para proyectos de informática,telecomunicaciones o multimedia, aunque algunos autores, de los que damos cuen-ta en la bibliografía, han realizado sus propias metodologías utilizando como refe-rencia, más o menos próxima, la estructura, recomendaciones y estándares del PMI,junto con otras metodologías, referencias o prácticas. Este será nuestro caso. Estosmateriales no son una adaptación del PMBOK al entorno TIC, sino una metodologíade gestión de proyectos TIC que utiliza como una de sus principales referencias elPMBOK, en la medida en que se está convirtiendo paulatinamente en un estándar dehecho dentro de las industrias TIC y poco a poco las empresas demandarán de susproveedores de servicios y del personal responsable de los proyectos metodologías yprobablemente certificaciones basadas en este estándar.

Fuente: Project Management Institute (2008). www.pmi.org

1.2. Los proyectos TIC

Los proyectos TIC tienen una mayoría de características semejantes a las de los

proyectos en genérico, pero tienen algunas peculiaridades o especialidades:

• Son más o menos replicables; es decir, hay muchos parecidos, por los pro-

ductos (en especial de software) o las metodologías que se utilizan. Muchas

metodologías y productos son estándar para resolver determinada clase de

problemas o parte de los mismos.

• Los especialistas son informáticos, ingenieros de telecomunicaciones (y,

más recientemente, de otras profesiones nuevas, como multimedia), pro-

fesionales que comparten un cuerpo de pensamiento, lenguaje, métodos

y aproximación a los problemas más comunes que en otras disciplinas del

conocimiento o de la práctica profesional.

• Algunas características de los productos TIC de hardware y software, refe-

ridas a su estabilidad, volatilidad, nivel y extensión del servicio. El cambio

tecnológico es más rápido en este entorno que en otros.

http://www.pmi.org


Los negocios modernos y la evolución de la tecnología han conducido a que

los proyectos TIC tengan cada vez más componentes no tecnológicos y los

proyectos de empresa cada vez más componentes TIC. Por este motivo, se pro-

duce una convergencia entre cualquier proyecto de empresa, y sus habilidades

y técnicas, y los proyectos TIC. Esto puede verse en la tabla 1, en la que se pre-

sentan ejemplos actuales de proyectos TIC. En definitiva, cualquier proyecto

TIC es un proyecto de negocio.

Tabla 1

Ejemplos de proyectos TIC

Desarrollo de aplicaciones a medida

Construcción de una base de datos

Adquisición e instalación de hardware, software y comunicaciones

Integración de sistemas

Implantación de software estándar

Diseño y construcción de un sitio web interactivo

Migración de aplicaciones

Instalación de una red wi-fi

Reingeniería de procesos y circuitos de información

En este material, adoptamos la perspectiva de que la mayoría de los proyectos

TIC son en realidad proyectos "mixtos", en los cuales además de fabricar, ins-

talar o implantar un producto técnico (que puede observarse y evaluarse físi-

camente), ocurren y probablemente deberían ocurrir cambios en los procesos

de trabajo de la organización cliente (o de la propia organización informáti-

ca), en las actitudes, los comportamientos y el conocimiento de las personas

y en el propio entorno (la "organización") en el que el producto o productos

deberán funcionar.

Los objetivos de los proyectos son, por tanto, compuestos y complejos

y la interacción con la organización es continua y cambiante.

Por eso, la aproximación a la gestión de proyectos en el ámbito de las TIC

en la actualidad tiene necesariamente que reconocer todos estos elementos y

ofrecer un marco general donde las "metodologías", técnicas y herramientas

(en el ámbito de la infraestructura de telecomunicaciones, del desarrollo de

software o en cualquier otro) son una parte de un todo más complejo.


1.3. Proyectos TIC y productos TIC

Para el profesional de las TIC, en especial si tiene el rol de gestor de un proyec-

to, es crucial distinguir entre la gestión del proyecto a lo largo de todo su ciclo

de vida y de toda la complejidad de procesos e interacciones que involucra,

y la producción técnica de un entregable determinado. Por tanto, una cosa

son las metodologías de gestión de proyecto y otra las metodologías de pro-

ducción, y de ningún modo deben confundirse. Lo que ocurre es que muchos

términos (fases, etapas, ciclo, procesos, entregables...) son comunes y muchas

metodologías de producción, sobre todo dentro de las compañías de servicios,

están incorporando internamente metodologías o aspectos de las metodolo-

gías de la gestión de proyectos, lo que hace que la distinción a veces parezca

puramente académica, pero no lo es.

La gestión de proyectos es un conjunto de procesos común,�más�am-

plio y complementario de la entrega (fabricación, instalación o servi-

cio) de un producto o servicio TIC. En un proyecto se hacen más cosas

(gestionar personas, presupuestos, riesgos, facturas, contratos, expecta-

tivas...) y se hacen de manera diferente (con otra clase de procesos y

documentos) a producir o instalar productos, y se utilizan otras habili-

dades.

Un buen jefe de producción o un gran analista o jefe de proyecto de desarrollo

de sistemas no es necesariamente un buen director de proyecto.

Lo veremos con más detalle cuando comparemos, por ejemplo, el ciclo típico

de desarrollo de un sistema de información en las metodologías estructuradas

(system development lyfe cycle, o SDLC) y las etapas o grupos de procesos de la

metodología de gestión de proyectos TIC.

Aun con el riesgo que tienen todas las metáforas, podemos decir que en un

proyecto TIC, los ciclos de gestión del proyecto y los de creación del producto

son como el yin y el yang (figura 2) o como dos caras de la misma moneda. Y,

desde luego, lo es así para el cliente, que difícilmente entenderá que hayamos

gestionado fantásticamente el proyecto, y el entregable o producto obtenido

sea un desastre y no cumpla los requisitos acordados; como tampoco enten-

derá que el producto sea perfecto, pero los usuarios estén insatisfechos y el

proyecto haya duplicado el tiempo y presupuesto acordado.

Distinción entre gestiónde proyecto y productoTIC

La diferencia entre proyecto yproducto TIC, según nuestraexperiencia, resulta ser uno delos puntos más complicadosde entender para el estudiantey de explicar para el consultor.


Figura 2. Proyecto y producto

Fuente: Marchewka, 2003


2. Dimensiones de un proyecto

2.1. Definiciones

En palabras del PMBOK, la gestión de proyectos (project management) es

la aplicación de conocimiento, habilidades, herramientas y técnicas a

las actividades de un proyecto para alcanzar sus requisitos.

El director, gerente o jefe de proyecto (project manager) es la persona responsa-

ble de cumplir los objetivos del proyecto. Para esto necesita manejar el difícil

equilibrio entre las exigencias de calidad, alcance, tiempo y coste, que compi-

ten entre sí. Y tiene que hacerlo en condiciones de incertidumbre o riesgo.

Examinemos la definición anterior, de la que extraeremos las dimensiones o

componentes principales de cualquier proyecto:

• Un proyecto debe tener objetivos bien definidos. Denominamos objetivos

a los resultados que se desean alcanzar. En un proyecto TIC es esencial

entender separada y adecuadamente cuáles son los objetivos de negocio

que se desean alcanzar y cómo los objetivos del proyecto permiten cumplir

con aquéllos.

• En un proyecto TIC, los resultados se deben expresar en términos de en-

tregables (productos, aplicaciones, documentación, etc.) que deben cum-

plir unos estándares de calidad y rendimiento.

• Denominamos calidad, principalmente, a la conformidad de los resulta-

dos con los objetivos y estándares establecidos al principio. La calidad tie-

ne una dimensión objetiva (conformidad con las normas) y una dimen-

sión subjetiva (la satisfacción del cliente y usuario, o calidad percibida).

• Denominamos alcance al contenido detallado y limitaciones o exclusio-

nes en los objetivos del proyecto, es decir, la declaración explícita de lo que

se hará y lo que no se hará. La gestión del alcance es acaso el componente

más crítico de la gestión de un proyecto TIC y al que el PMBOK concede

mayor importancia.

• Para realizar el proyecto, se requieren recursos humanos y materiales. El

valor económico de estos recursos constituye el coste del proyecto.

Project manager

En este módulo usaremos lasexpresiones director, gerente yjefe de proyecto indistintamen-te.


• A diferencia de otras tareas repetitivas, el proyecto se desarrolla dentro de

un límite temporal, el tiempo de duración del proyecto, desde su inicio

a su terminación.

• El riesgo del proyecto deriva de la incertidumbre de alcanzar los resultados

en el tiempo, coste y niveles de calidad acordados y otros aspectos de ges-

tión. La identificación, gestión y respuesta adecuada frente a la ocurrencia

de riesgos es fundamental en un proyecto TIC.

• El equipo de proyecto es el grupo de personas constituido para desarro-

llarlo. Cada vez más, en los equipos de proyecto intervienen personas a

tiempo completo y otras personas a tiempo parcial. Y algunas de ellas serán

asignadas de una manera estable al proyecto (que es su único cometido) y

otras representarán a la organización usuaria (el cliente).

• El jefe�de�proyecto es el responsable último del éxito o el fracaso de un

proyecto, tanto desde el punto de vista técnico como económico. Para

esto, tiene asignados los recursos del proyecto.

• Todos los proyectos se realizan por encargo o por contrato de alguien, el

cliente, ya sea éste interno o externo a la organización. El cliente es quien

determina y aprueba en último lugar los objetivos, recursos, coste y dura-

ción del proyecto, y las modificaciones o revisiones.

• En el cliente, hay usuarios que serán los que deban utilizar el proceso o

sistema que se entrega al término del proyecto. El cliente y los usuarios

tienen necesidades y objetivos de negocio que justifican la realización del

proyecto, pero también tienen resistencias al cambio que deben manejar-

se.

De todos estos componentes, hay un cuadrilátero de elementos críticos, inter-

dependientes e interrelacionados. No se puede manejar uno de ellos sin que

afecte a los demás: son los conceptos de alcance, calidad, tiempo y coste. Las

decisiones importantes del jefe de proyecto y del cliente, a lo largo de todo

el trabajo, tienen que ver con estos elementos. No puede asegurarse el mis-

mo alcance y la misma calidad si disminuye el tiempo o el presupuesto. No

puede ampliarse el alcance, sin ampliar el tiempo o los recursos. Si sufrimos

una desviación en el tiempo de ejecución, esto afectará al coste, la calidad o

el alcance, etc.


Figura 3. Elementos críticos de la gestión de un proyecto

La gestión de proyectos dirigida a objetivos (goal directed projectmanagement)

La segunda, pero no menos importante, referencia metodólogica que utilizamos eneste material es GDPM (la gestión de proyectos basada en objetivos), introducida enNoruega a principios de los ochenta por tres consultores informáticos, Erling Ander-sen, Kristoffer Grude y Tor Haug y que se convirtió después en el estándar metodo-lógico de las compañías de consultoría Coopers & Lybrand, PricewaterhouseCoopersy, en parte, de la actual IBM Business Consulting, que adquirió en el año 2002 ladivisión de consultoría de la anterior.

GDPM hace énfasis en la necesidad de alinear los cambios en los sistemas de infor-mación con el desarrollo de las personas y la organización (lo que modernamentese ha llamado la "gestión del cambio") y, en consecuencia, pone el acento en el ladohumano y organizativo de los proyectos y en la necesidad de desarrollar desde elinicio una comprensión común de los objetivos y enfoque del trabajo y una involu-cración y compromiso compartidos entre todos los que participan en el proyecto, enparticular, la parte funcional y de negocio.

Las herramientas básicas de GDPM son muy sencillas:

• El plan de hitos (milestones) descompone los objetivos del proyecto en resultadosa conseguir, los relaciona entre sí y establece las condiciones para verificar quese han conseguido.

• La matriz de responsabilidades establece el rol de todos los interesados en el pro-yecto y la responsabilidad para la toma de decisiones, la participación, comuni-cación e información en cada hito.

El resto de las herramientas de proyecto (y las diferentes metodologías, incluidas lasguías de PMBOK) son fácilmente integrables con estas dos, de manera que los obje-tivos de cliente y de proyecto desde el punto de vista de negocio y la aportación decada parte desde el punto de vista de la gestión del trabajo siempre estén presentesy no se pierdan en una maraña de diagramas, donde frecuentemente los árboles nodejan ver el bosque y la documentación del detalle hace perder de vista el porqué ypara qué estamos haciendo un proyecto.

Fuente: Andersen y otros (2000). www.gdpm.com/

2.2. Ámbitos de conocimiento experto en la gestión de proyectos

Como se puede observar, estamos integrando con una perspectiva ecléctica

definiciones tradicionales en la gestión de proyectos empresariales e informá-

ticos y otras nuevas que tienen una importancia cada vez mayor.

http://www.gdpm.com/


El PMBOK reconoce cinco áreas o ámbitos principales de conocimiento

experto que el equipo de proyecto debe adquirir o disponer:

1) Los propios del PMBOK (en su caso), es decir, el conocimiento de los pro-

cesos�y�herramientas�de�gestión�de�proyectos conocidos y codificados por

la profesión y la experiencia.

2) El conocimiento,�estándares�y�regulaciones�propios del área técnica, fun-

cional o sectorial en la que se desarrolla el proyecto (por ejemplo, las normas

ISO o las gubernamentales, que afectan a determinadas industrias).

3) El conocimiento�del�entorno organizativo, físico, cultural, político y social

en el que el proyecto se desarrolla.

4) Los conocimientos�de�gestión�de�empresas, en general, y los propios de las

áreas funcionales o técnicas en las que se desarrolla el trabajo (p. ej., finanzas

o atención al cliente).

5)�Habilidades�interpersonales, o lo que aquí llamaremos "el lado humano

de la gestión de proyectos", como son las habilidades de comunicación, mo-

tivación, liderazgo, negociación, resolución de problemas, gestión de conflic-

tos, etc.

La gestión de proyectos del siglo XXI

Harold Kerzner, que es un gurú reconocido en esta disciplina, ha hecho ver que a co-mienzos del siglo XXI la gestión de proyectos como especialidad integra conocimien-tos y prácticas de varias disciplinas independientes:

• Gestión�de�proyecto: planificación, distribución, organización y control de tiem-pos y costes.

• Gestión�total�de�la�calidad: el proceso de asegurar que el resultado final de unproducto o servicio cumple las expectativas del cliente.

• Ingeniería�concurrente: realizar trabajos y proyectos en paralelo, más que enserie, para comprimir el plazo de realización sin incurrir en riesgo.

• Gestión�del�cambio: transformación de actitudes y comportamientos de la orga-nización para asimilar nuevos proyectos.

• Gestión�de�riesgos: identificar, cuantificar y responder a los riesgos del proyecto,y minimizar el impacto sobre resultados, tiempo y coste.


Figura 4

Fuente: Kerzner (2001)


3. Ciclo de vida de un proyecto

Las empresas y los autores suelen definir y clasificar de varios modos diferentes

las fases de un proyecto, o más propiamente del ciclo de vida del proyecto.

Aquí adoptaremos la del PMBOK que se muestra en la figura 5.

Según el PMBOK, el proyecto se divide en cinco etapas o grupos de pro-

cesos:

• Iniciación

• Planificación

• Ejecución

• Seguimiento y control

• Cierre

Figura 5. Ciclo de vida del proyecto

Frente a otras clasificaciones posibles, ésta intenta mostrar y visualizar más

claramente la importancia de las fases anteriores y posteriores a la ejecución

y el peso que en el conjunto del proyecto tienen y deben tener cada vez más.

La que llamamos de iniciación incluye la aprobación y definición preliminar

del proyecto. La fase de seguimiento y control es permanente y paralela a todo

el ciclo de gestión. Y, como veremos, PMBOK reconoce la necesidad de una

replanificación permanente o iterativa a lo largo de la ejecución.

Como se muestra en el diagrama de la figura 6 (elaborado por Kerzner para

cualquier clase de proyecto en cualquier clase de sector industrial), del conjun-

to de recursos dedicado a un proyecto, las fases que no son la ejecución repre-

sentan más o menos la misma carga de recursos que las que son de ejecución.


Figura 6. Distribución típica de recursos en el ciclo de vida

Fuente: Kerzner (2001)

3.1. Iniciación

En la etapa de iniciación, la dirección de la compañía identifica de di-

ferentes maneras un problema o necesidad, lo interpreta o conceptuali-

za en forma de proyecto, encarga y analiza su viabilidad técnica y eco-

nómica y los riesgos y, en su caso, lo aprueba.

Habitualmente, en la agenda de la dirección y en el presupuesto de la com-

pañía, un proyecto compite con otros para ser aprobado. Por lo tanto, esta

primera fase suele incluir actividades de priorización y selección de proyectos.

El producto de esta fase se documenta en formatos propios del proceso presu-

puestario general de la compañía o del presupuesto del área de organización y

sistemas de información. En otras ocasiones, un proyecto es parte de un plan,

programa o proyecto mayor, que gestiona una oficina de proyectos.

En todo caso, el resultado de esta fase es un mandato (project charter, o "acta

de constitución" del proyecto) y una definición inicial del contenido, alcance

y requisitos del trabajo a desarrollar (preliminary project scope statement, en la

expresión que se usaba en la versión 3 del PMBOK y que nos parece interesante

mantener para proyectos TIC.

Nota

En este punto, hemos introducido algunos cambios sobre la 4.ª edición del PMBOK, deacuerdo con otras metodologías, la práctica de las empresas de servicios TIC y nuestrapropia práctica como consultores. Para el PMBOK, por ejemplo, las actividades previas ala aprobación no forman parte del proyecto en sí mismo. Asimismo, la definición inicialde alcance, que sí formaba parte de la 3.ª edición, ahora ha pasado a la etapa o grupode planificación.


3.2. Planificación

La planificación detallada del trabajo es la etapa o grupo de procesos en

la que se establece la hoja de ruta que tendrá que seguir el proyecto para

alcanzar sus objetivos y producir los resultados o entregables esperados.

En primer lugar, revisar y, sobre todo, obtener un acuerdo o contrato explícito

acerca de los temas del proyecto. El resultado principal es un documento deta-

llado de alcance (scope definition, o documento de alcance), es decir, la defini-

ción, como no nos cansaremos de decir, de lo que se hará y lo que no se hará.

En la asignatura, siguiendo la metodología de gestión de proyectos orientada

a objetivos (goal directed project management), separamos la planificación estra-

tégica del proyecto (enfocada a hitos y objetivos) de la planificación operativa

(enfocada a actividades y tareas), y animamos al jefe de proyecto a manejar

permanentemente este zoom entre uno y otro ámbito. En términos del PM-

BOK, el resultado principal de la planificación estratégica es la descomposi-

ción del trabajo en partes o paquetes de trabajo más pequeños, o EDT (work

breakdown structure, o estructura de distribución del trabajo), que en realidad

son entregables (deliverables) parciales o generales.

Seguidamente, se realiza la planificación operativa, descomponiendo cada

EDT en actividades, poniéndolas en secuencia, estimando los recursos necesa-

rios y estableciendo un calendario preliminar. Finalmente, se estiman los cos-

tes y se elabora el presupuesto.

Una de las mayores fortalezas del PMBOK es el ejercicio de formalización del

conjunto de procesos de planificación y gestión que se consideraban hasta

hace no mucho "auxiliares" o "complementarios", y que la práctica de trabajo

en proyectos TIC y en otras disciplinas ha demostrado que son fundamenta-

les. De este modo, la fase de planificación incluye también los planes de ca-

lidad, recursos humanos, comunicación, gestión de riesgos y administración

y compras.

3.3. Ejecución

La planificación es tan importante que la fase de ejecución habitual-

mente contiene un ejercicio permanente de preparación de planes más

detallados, revisión de los planes elaborados y comprobación de su es-

tado de avance, replanificación de trabajos, etc.

La gestión y documentación rigurosa de los cambios es otro aspecto central de

esta fase. Además de estos trabajos de seguimiento y reporte, la ejecución es un

ejercicio de gestión y de manejo de personas e incidentes, que, en proyectos de


cierto tamaño, justifican de sobras la dedicación de recursos experimentados

sólo para controlar y manejar su ejecución. La ejecución incluye también los

procesos de aseguramiento de la calidad, gestión de recursos humanos y técni-

cos, gestión de la comunicación y administración de las compras y contratos.

La ejecución es un baño de realidad que se aprende sobre todo con la expe-

riencia, la repetición y los retos progresivos.

3.4. Seguimiento y control

Como hemos dicho, los procesos de seguimiento y control puede decir-

se que son permanentes y paralelos a todo el proyecto, especialmente

"pesados" en la fase de ejecución. Todos los aspectos contenidos en los

diferentes planes deben ser perseguidos, evaluados y, en su caso, reajus-

tados.

Los procesos más críticos en esta fase son los de control de cambios (cualquier

petición o incidencia que afecta a la planificación inicial) y los de gestión de

riesgos.

3.5. Cierre

La etapa de cierre incluye todas las actividades necesarias para finalizar

la gestión del proyecto y completar las obligaciones contenidas en el

contrato.

Normalmente incluye la aceptación de los productos por parte del cliente,

hacer las revisiones acordadas posteriores al cierre, cerrar los contratos con el

cliente y proveedores, documentar las lecciones aprendidas, etc.

En la tabla 2 se muestra un resumen del ciclo de vida de un proyecto TIC y

de los diferentes procesos involucrados, que se explicarán más extensamente

en los siguientes capítulos.


Tabla 2


4. El ciclo de gestión de proyecto comparado con elciclo de producción

De igual modo que el proyecto tiene un ciclo de vida de gestión del proyecto,

los productos que se obtienen en un proyecto TIC tienen su propio ciclo de

vida. Una cosa y otra se relacionan, hemos dicho antes que son como el yin y

el yang o las dos caras de la misma moneda, pero�no�son�lo�mismo, aunque

para seguir con la confusión compartan a veces la apariencia o la terminología.

De todos los productos TIC y de todas las metodologías de producción,

la más común y conocida es la SDLC, que representa las fases secuencia-

les por las que pasa un sistema de información a lo largo de su vida útil.

Aunque varía según la metodología que se use, normalmente se reconoce que

este sistema sigue las siguientes cinco fases (figura 7):

Figura 7. Fases del ciclo de vida de desarrollo de un sistema de información

1) En la fase de planificación, se identifican los objetivos del producto y se

establecen los procesos, actividades, herramientas, métodos de trabajo y re-

cursos, dentro del tiempo y presupuesto disponible.

2) En la fase de análisis, se analiza el sistema tal como funciona en la actuali-

dad (de forma manual o automatizada), o como se dice in inglés as is, se toman

los requisitos de las partes interesadas y seguidamente se establece un modelo

lógico de funcionamiento futuro o to be.

3) En la fase de Diseño, a partir del análisis de requisitos y del modelo lógi-

co, el equipo de trabajo establece la arquitectura de hardware, bases de datos,

comunicaciones, interfaces de usuario, integración con otras aplicaciones y,

sobre todo, la arquitectura de software o programas de aplicación.

SDLC

Systems development life cycle.En castellano, ciclo de vida dedesarrollo de un sistema de in-formación.

4) En la fase de construcción se realiza el desarrollo técnico o construcción

del sistema, las pruebas y la instalación, además del entrenamiento, soporte a

usuarios, soporte técnico y documentación del sistema.

5) La fase de mantenimiento�y�soporte es parte intrínseca del ciclo de vida del

sistema, aunque no siempre forma parte del proyecto, salvo las correcciones

de errores y el soporte a usuarios durante un tiempo acordado.

Fase de implantación

Algunas metodologías separanla implantación como fase se-parada, o llaman a toda estafase implantación en sí misma.


Si comparamos este proceso con el que hemos mostrado en las páginas ante-

riores para la gestión de proyectos, veremos que la mayoría de sus contenidos

(al menos las fases de diseño y construcción, en su casi totalidad) forman parte

de los procesos de ejecución. La fase de planificación puede incorporarse co-

mo parte de los procesos de planificación de la gestión de proyectos, en tanto

que aporta el instrumental técnico y el know-how específico de cada tipo de

proyecto. La fase de mantenimiento y soporte suele estar fuera del proyecto.

La visión de PMBOK

Si lo miramos al revés, los procesos de iniciación, seguimiento y control y cierre noestán habitualmente dentro de las metodologías de desarrollo estructurado de siste-mas. Y desde luego, estas metodologías no contemplan muchísimos de los procesos,subprocesos y actividades que ha ido desarrollando la disciplina de gestión de pro-yectos, entre ellos algunos tan críticos como la gestión de la comunicación, la gestiónde los recursos humanos o la gestión de riesgos.

Algunos autores de la familia del PMBOK (Marchewka, 2003), consideran que todoel ciclo de vida de desarrollo forma parte de los procesos de ejecución. Otros (Snydery Parth, 2008) consideran que las actividades de análisis y diseño forman parte de lasde planificación, mientras que la construcción sería propiamente del mundo de laejecución. Por lo tanto, para unos y otros, el ciclo de vida de desarrollo es una partede la gestión de proyectos sin mayor discusión.

En realidad, lo más importante, en nuestra opinión, es entender cuál es la

diferencia entre fabricar un producto y hacer un proyecto, y cuáles son los

principios de la gestión de proyectos que son intrínsecamente distintos de

la fabricación (o la instalación) de productos o la prestación de otra clase de

servicios. Y es ahí, en el límite, donde encontramos las diferencias entre unas

y otras metodologías:

• La gestión de proyectos se aplica a cualquier clase de proyecto TIC, sea de

desarrollo de aplicaciones, de implantación de productos estándar, de ins-

talación de infraestructuras o de prestación de servicios (siempre que éstos

tengan la naturaleza de proyecto y no sean simplemente el arrendamiento

de una parte de las operaciones ordinarias de la empresa).

• La gestión de proyectos no es secuencial o por fases, sino que consiste en

la aplicación diferencial de un conjunto de habilidades, herramientas y

actividades (que llamamos grupos de procesos o áreas de conocimiento)

a lo largo de todo el ciclo de vida de cualquier proyecto. Es, por lo tanto,

iterativa y permanente.

• Cuantitativa y cualitativamente, el esfuerzo más importante de la gestión

de proyectos no se produce en los procesos de ejecución, sino en el res-

to de los procesos involucrados, especialmente en la planificación y en el

control. Los procesos de producción (normalmente incluidos en la ejecu-

ción) son la parte individualmente mayor, pero en todo el conjunto sólo

representan un 40% de la gestión del proyecto.


• La gestión de proyectos está orientada, principalmente, a la satisfacción

del cliente y de sus objetivos de negocio, mientras que la fabricación de

un producto está orientada a la satisfacción de unos requisitos y el cum-

plimiento de unos estándares de calidad.

• La gestión de proyectos involucra habilidades, herramientas y actividades

más amplias y variadas, aunque probablemente menos especializadas, que

las de la fabricación de un producto. Es probable que tengan más que ver

con la gestión de empresas que con la ingeniería. Y que se adquieran más

con la experiencia que con la formación.

• Según muestra la experiencia y la literatura de análisis de proyectos exito-

sos y fracasados, los elementos críticos de un proyecto no tienen que ver

tanto con la calidad de la producción, sino con la calidad de la gestión

del proyecto.

Esto lo examinaremos a continuación.


5. Factores críticos de éxito en un proyecto

Las expresiones de éxito y fracaso relacionadas con un proyecto, aunque om-

nipresentes, son en parte subjetivas: dependen del color con que se mira. Es

difícil encontrar éxitos y fracasos completos en cualquier clase de proyectos.

En términos generales, un proyecto se considera un fracaso si:

• no se han alcanzado los objetivos o resultados previstos,

• se han sobrepasado los tiempos asignados,

• se han sobrepasado los recursos o costes previstos,

• no se han alcanzado los estándares de calidad deseados.

• el cliente y los usuarios principales no están satisfechos.

Según el Standish Group, en el 2009, de los proyectos realizados sólo el 32%

alcanzaron sus objetivos, un 24% fracasaron y un 44% obtuvieron resultados

dudosos o cuestionados. Estos resultados son peores que los de los años ante-

riores (Standish Group Chaos Report, 2010).

Se puede pensar que los proyectos fallan porque la gente no sabe hacerlos

por un desconocimiento principalmente técnico. No es así, ni es la razón más

frecuente. Un proyecto falla por una gran variedad de razones; en la tabla 3

se pueden ver algunas de éstas:

Tabla 3

Causas frecuentes de fracaso en los proyectos TIC

Falta de compromiso de la dirección.

Los usuarios no se involucran.

Falta de conocimiento técnico por parte del equipo.

Falta de madurez o estabilidad de la tecnología.

Malas relaciones con otras partes o departamentos interesados en el proyecto.

Mala gestión administrativa y económica del trabajo.

Falta de supervisión sobre el equipo de proyecto.

Falta de dedicación del gerente y supervisores.

Pocas reuniones de seguimiento y control.

Documentación insuficiente de progreso y seguimiento.

Pésima planificación.

Fuente: Rodríguez, García, Lamarca (2007)


Causas frecuentes de fracaso en los proyectos TIC

Venta y contratación por debajo de las necesidades de tiempo y recursos.

Plazos de ejecución no realistas.

Mala definición de autoridad y roles dentro del equipo de proyecto.

Mal ambiente de trabajo y falta de comunicación en el equipo.

Asignación inadecuada de personal en cantidad o en los perfiles.

No se identificaron los riesgos.


En la actualidad, por los motivos de contexto que se han mostrado anterior-

mente (mayor complejidad técnica y organizativa, mayor presión de tiempos

de entrega, cambio tecnológico), el riesgo de fracaso es aún más alto, aunque

también se reconoce una mayor conciencia de los directivos de empresa y una

mejora en la disciplina y profesionalización de la gestión de proyectos, que ha

contribuido a reducir los fallos.

Sin embargo, de todas las razones de la tabla, hay tres que aparecen de

manera estable como las más importantes o, al menos, las más citadas:

1) Gestión de proyecto deficiente o inadecuada (32% de los proyectos

fallidos).

2) Falta de comunicación con el cliente o el equipo de trabajo (20%).

3) Valoración incorrecta del alcance y complejidad del proyecto (17%).

Fuente: Standish Group y KPMG

Denominamos factores�críticos�de�éxito (FCE; en inglés critical success factors,

CSF) a las condiciones necesarias individualmente y en conjunto suficientes

para que ocurra el éxito.

La literatura, la experiencia de gerentes de proyecto y las metodologías de las

firmas comerciales suelen disponer de listas de esta clase. Nosotros hemos pre-

ferido aquí una lista más exhaustiva, en la que intentamos balancear los as-

pectos técnicos, organizativos y de gestión o dirección del proyecto. Como se

muestra en la figura 8, un proyecto tiene éxito cuando:

1) Están claramente establecidos el valor y los beneficios de negocio (aumento

de ingresos, reducción de costes, etc.) que se obtienen al realizarlo.

2) Se establecen claramente los objetivos, resultados y productos que hay que

obtener.


3) Se establecen claramente el alcance y las limitaciones del trabajo.

4) Se realizan, controlan y actualizan planes detallados, en los cuales los hitos,

entregables y actividades aparecen bien especificados en el tiempo.

5) Se asegura constantemente el apoyo de la dirección, en términos de autori-

dad, consistencia de los objetivos y provisión de recursos.

6) Se escuchan e interpretan las expectativas de todos los usuarios y partes

involucradas y se planifican y gestionan adecuadamente. Se asegura la acep-

tación del trabajo por parte de los usuarios y otras partes interesadas.

7) Se asignan los recursos adecuados, con las habilidades necesarias, tanto téc-

nicas como de gestión de proyectos, así como otras habilidades funcionales

que se requieran en cada caso.

8) Se monitoriza, evalúa y se obtiene retroalimentación puntual a lo largo de

toda la ejecución del proyecto.

9) Existen tecnologías maduras y personal formado y disponible para dar el

servicio.

10) Se identifican a tiempo y se gestionan las incidencias, crisis y desviaciones.

Para facilitar su representación gráfica y la fijación de los conceptos para el

alumno, hemos llamado a estos factores "Los diez mandamientos de la gestión

de proyectos".

Figura 8. Factores críticos de éxito: Los diez mandamientos de la gestiónde proyectos



6. La cultura de proyecto dentro de lasorganizaciones: la gestión por proyectos comomodelo organizativo

Desde los años ochenta, muchas organizaciones y autores han encontrado que

en la gestión de proyectos y en las empresas que se dedican profesionalmente a

hacer proyectos, como las ingenierías y consultoras, existen valores, culturas,

costumbres y procesos de trabajo que pueden ser exportados a otras empresas

(Drucker, Peters, Waterman).

Algunas industrias, como las de construcción de edificios, barcos o aviones,

son inevitablemente industrias de proyecto y orientadas por proyecto. En casi

todas las empresas se hacen proyectos, y algunos departamentos como los de

informática o investigación y desarrollo o marketing parecen más orientados

por proyectos que otros.

De las empresas orientadas por proyectos, y en particular de las de servicios

profesionales, se pueden obtener algunas lecciones:

• Están más orientadas al cliente (costumer focused) que al producto o la fun-

ción. La opinión y los requisitos del cliente cuentan y son una fuente de

desafío y exigencia para la gestión del día a día.

• Están más orientadas a los resultados e hitos (goal oriented) que a las acti-

vidades y los inputs o recursos. Convierten cualquier actividad en un pro-

ducto final entregable a un cliente que debe cumplir unas especificaciones.

• Están orientadas por procesos (process oriented) y no por departamentos

o funciones dentro de la organización. Cada proyecto se compone de un

proceso o conjunto de procesos relacionados.

• Fomentan el trabajo en equipo (team work oriented) más allá de las barreras

funcionales o jerárquicas dentro de la organización. El valor de un miem-

bro del equipo está en su rol dentro del proyecto y en su aportación al con-

junto, con independencia de su categoría o grado jerárquico. Un gerente

de un proyecto puede ser un miembro de equipo en otro proyecto distinto.

• Casi nunca existe una función puramente directiva. Los directivos son

también productores y miembros de equipos de proyecto.

• Los recursos humanos se evalúan continuamente según sus competencias

y habilidades objetivas que se muestran y visualizan fácilmente a lo largo

del proyecto. La retroalimentación (feedback) inmediata por parte de los

Bibliografía

Este apartado está basado enel manual:J.�R.�Rodríguez;�J.�GarcíaMínguez;�I.�Lamarca�Oroz-co (2007). Gestión de proyec-tos informáticos: métodos, he-rramientas y casos. Barcelona:UOC.


supervisores y enfrentarse frecuentemente a retos superiores y distintos

aumentan el aprendizaje y la satisfacción personal en el trabajo.

• Trabajan por fechas límite de entrega (deadlines), lo que produce una ten-

sión de logro y productividad normalmente mayor que en otras organiza-

ciones.

• Cada proyecto es, incluso económicamente y en términos de reporte, una

empresa, de la que se espera un resultado de beneficio. Esta situación pre-

siona al gerente de proyecto para optimizar los recursos y genera en el

equipo un sentido de propiedad y compromiso.

• Muchas de estas empresas son o han sido cooperativas con una cultura del

mérito profundamente arraigada. La evolución profesional del empleado

conduce a ser directivo y socio de la empresa (aunque esto va cambiando

a medida que las cooperativas de socios se convierten en corporaciones de

empleados a sueldo).

• Las organizaciones de proyecto son organizaciones orientadas comercial-

mente. Todo el mundo aspira a vender un proyecto, hacerlo crecer cuando

se ha conseguido o replicarlo en otro cliente.

La consolidación y madurez de la gestión de proyectos como materia

teórica interdisciplinar y como profesión, la emergencia de un número

cada vez mayor y más formado de gerentes de proyectos y las nuevas

presiones del entorno económico están llevando a las empresas a adop-

tar formas organizativas más flexibles y ad hoc, y a reconocer la gestión

por proyectos como principio inspirador de estas transformaciones.

Por qué son tan importantes los proyectos en la empresa

"A lo largo de los años de desarrollo de la gestión de proyectos, la alta dirección de lasempresas ha reconocido el papel que tienen los proyectos en la gestión estratégica delas organizaciones. Los directivos deberían observar de manera regular el potencial y lascontribuciones reales que los proyectos tienen en la gestión del cambio dentro de laempresa. Más aún:

• Los proyectos son elementos básicos en el diseño y ejecución de las estrategias de laorganización.

• La alta dirección gana mayor visión de la trayectoria estratégica de la empresa cuandoobserva los proyectos que se están ejecutando en la organización.

• Los equipos directivos deberían ser conscientes de cómo la gestión de proyectos pue-de ayudar en el desarrollo de nuevos productos, servicios y procesos organizativos."

D. I. Cleland; L. R. Ireland (2000). Project Manager's Portable Handbook


En grandes organizaciones o departamentos de servicios informáticos recien-

temente se están integrando metodologías de gestión de proyectos con los mo-

delos de gestión de operaciones (como pueden ser ITIL o CMM). La consultora

CSC propone un modelo de madurez progresiva de la función de gestión de

proyectos alineado con el CMM (capability maturity model) para el desarrollo

de software del Software Engineering Institute.

Bibliografía

Computer�Sciences�Corpo-ration (2003). "Improvingthe Performance of Your Pro-ject Management Office".Waltham (MA, Estados Uni-dos).


7. Resumen

La gestión de proyectos es una disciplina cada vez más importante en el mun-

do de las TIC y, en general, de la gestión de empresas. La gestión de proyectos

proporciona al profesional de las TIC un método general para abordar cual-

quier clase de proyecto, aunque debe ayudarse de las metodologías de ejecu-

ción propias del tipo de proyecto de informática, telecomunicaciones o mul-

timedia de que se trate en cada caso.

Un proyecto es un conjunto de actividades llevado a cabo durante un tiem-

po por un conjunto de personas para crear un producto, servicio o resultado

único. La temporalidad, la elaboración progresiva y la creación de un resulta-

do único es lo que distingue el proyecto de las operaciones ordinarias de la

empresa.

La gestión de proyectos es la disciplina de conocimiento y experiencia que

permite planificar, organizar y gestionar proyectos. Esto quiere decir dos cosas:

a) Asegurar que los proyectos se completan satisfactoriamente y que se consi-

guen sus productos y resultados últimos.

b) Hacerlo de manera que se pueda predecir y controlar su evolución, respon-

der a los cambios y explicarlo satisfactoriamente al cliente y al equipo de pro-

yecto.

Todo proyecto tiene un cliente o sponsor y unos objetivos a alcanzar, con un

alcance o nivel de detalle determinado, en un tiempo y presupuesto acordado

y con unos estándares de calidad establecidos y medibles. Alcance, calidad,

tiempo y presupuesto son las cuatro magnitudes más importantes de un pro-

yecto y las cuatro están interrelacionadas.

El director o gerente o jefe de proyecto es el responsable último del éxito o el

fracaso del proyecto, tanto desde el punto de vista técnico como económico.

Para esto, tiene asignados los recursos del proyecto y las capacidades de deci-

sión por parte del cliente o sponsor.

En la actualidad la gestión de proyectos es una disciplina muy amplia y com-

pleja que incluye múltiples áreas de conocimiento experto: las propias de la

gestión de proyectos, las del área técnica, funcional o sectorial en la que se

realiza el trabajo, conocimientos de gestión de empresas y habilidades inter-

personales.


El PMBOK (o cuerpo de conocimiento de la gestión de proyectos) es el estándar

de gestión de proyectos reconocido internacionalmente y que se aplica en

toda clase de sectores y ámbitos técnicos, incluidas las industrias TIC, que

utilizaremos como referencia metodológica principal en este material, aunque

adaptado a las peculiaridades de la gestión de las TIC, a nuestra experiencia, la

de las empresas de servicios y otra literatura académica. La 4.ª edición (2008)

se estructura en cinco grupos básicos de procesos, nueve áreas o ámbitos de

conocimiento y cuarenta y dos procesos diferentes, además de una biblioteca

de técnicas y herramientas.

Los procesos que componen la gestión de proyectos son:

1) Iniciación

2) Planificación

3) Ejecución

4) Seguimiento y control

5) Cierre

El esfuerzo cuantitativo y cualitativo empleado en la ejecución es menor que

en todos los demás sumados.

Es importante distinguir el proceso de gestión de un proyecto TIC del ciclo de

producción de un sistema o producto TIC. Normalmente, las metodologías de

desarrollo de productos se integran, en la mayoría de sus componentes, dentro

de los procesos de ejecución.

Muchos proyectos fallan por una gestión inadecuada, más que por un produc-

to que no funciona. Las causas más frecuentes de error no son técnicas sino

de gestión, especialmente:

1) gestión inadecuada del proyecto,

2) falta de comunicación y

3) valoración incorrecta del alcance y la complejidad del proyecto.

La gestión de proyectos. Conceptos básicosIntroducciónObjetivosÍndice1. Qué es un proyecto1.1. El proyecto y las demás cosas1.2. Los proyectos TIC1.3. Proyectos TIC y productos TIC

2. Dimensiones de un proyecto2.1. Definiciones2.2. Ámbitos de conocimiento experto en la gestión de proyectos

3. Ciclo de vida de un proyecto3.1. Iniciación3.2. Planificación3.3. Ejecución3.4. Seguimiento y control3.5. Cierre

4. El ciclo de gestión de proyecto comparado con el ciclo de producción5. Factores críticos de éxito en un proyecto6. La cultura de proyecto dentro de las organizaciones: la gestión por proyectos como modelo organizativo7. Resumen

proyectos. La gestión de Conceptos básicosuoc.gitlab.io/2015/gestion...

Documents

Transcript of proyectos. La gestión de Conceptos básicosuoc.gitlab.io/2015/gestion...