Sie sind auf Seite 1von 8

UNIVERSIDAD POLITECNICA DE PACHUCA

MATERIA: ADMINISTRACIION DE PROYECTOS


Instrucciones de actividad: Despus de realizar la lectura del documento se pide realizar un resumen general,
especificando: Qu es la Administracin de proyectos? Cules son las funciones de la administracin? La
importancia de la Administracin de proyectos, sus funciones. Qu es un administrador de Proyectos?
Definicin de un Proyecto, Cules son los elementos del proyecto?, porqu se le debe de dar holgura a un
proyecto?, Cundo un cambio en el proyecto es necesario?, Cules son las fuentes de los errores en los
proyectos? Cules son los aspectos a considerar en la gestin de riesgo del proyecto y en qu consisten?

I N T R O D U C C I N
Este trabajo presenta varios puntos referentes a la administracin de proyectos y a la persona encargada de conducirlos
hacia un fin exitoso. Se exponen el significado de la administracin de proyectos dentro de las organizaciones actuales, su
importancia, funciones y se explica por qu se le considera una solucin al problema surgido del incremento de
operaciones, dentro de las actividades que llevan a cumplir un objetivo. Tambin se hace mencin al papel que cumple un
administrador de proyectos dentro de una organizacin y las tareas que lleva a trmino para la realizacin de las metas
propuestas.
QU ES LA ADMINISTRACIN DE PROYECTOS ?
Es la planeacin, organizacin, direccin y control de los recursos para lograr un objetivo a corto plazo. Tambin se dice
que la administracin de proyectos ocurre cuando se da un nfasis y una atencin especial para conducir actividades no
repetitivas con el propsito de lograr un conjunto de metas. Esta actividad es llevada a cabo por un conjunto de
administradores que actan como agentes unificadores para proyectos particulares, tomando en cuenta los recursos
existentes, tales como el tiempo, materiales, capital, recursos humanos y tecnologa.
La administracin de proyectos implica una gran importancia, por lo que es usada en una gran diversidad de
campos; desde proyectos espaciales, en bancos, en desarrollo de sistemas en computadora, en procesamiento de
hidrocarbono, en la industria petroqumica, en telecomunicaciones, en defensa nacional, etc.
Los cambios tecnolgicos, la necesidad de introducir nuevos productos al mercado, las cambiantes exigencias de los
consumidores de productos, entre otras cosas, incrementan el fluido de operaciones en una organizacin, provocando que
los mtodos de administrativos convencionales sean inadecuados. Por esta razn la administracin de proyectos es
importante, ya que ofrece nuevas alternativas de organizacin.
Sirve para aprovechar de mejor manera los recursos crticos cuando estn limitados en cantidad y/o tiempo de
disponibilidad. Tambin ayuda a realizar acciones concisas y efectivas para obtener el mximo beneficio.
FUNCIONES DE LA ADMINISTRACIN
La administracin procura siempre el mximo aprovechamiento de los recursos, mediante su utilizacin eficiente. Las
principales funciones de la administracin se engloban en planeacin, organizacin, direccin y control.
Durante la planeacin se decide anticipadamente qu, quin, cmo, cundo y por qu se har el proyecto. Las tareas ms
importantes de la planeacin son determinar el status actual de la organizacin, pronosticar a futuro, determinar los
recursos que se necesitarn, revisar y ajustar el plan de acuerdo con los resultados de control y coordinar durante todo el
proceso de planeacin.
La organizacin realiza actividades en grupo, de asignacin y asesoramiento, y proporciona la autoridad necesaria para
llevar a cabo las actividades.
Dentro de esta etapa se identifica, define y divide el trabajo a realizar, se agrupan y definen los puestos, se proporcionan
los recursos necesarios y se asignan los grados de autoridad.
El siguiente paso es la direccin, la cual sirve para conducir el comportamiento humano hacia las metas establecidas
Aqu se comunican y explican los objetivos a los subordinados, se asignan estndares, se entrena y gua a los subordinados
para llegar a los estndares requeridos, se recompensa el rendimiento y se mantiene un ambiente motivacional.
Por ltimo se encuentra el control, que se encarga de medir el rendimiento obtenido en relacin a las metas fijadas. En
caso de haber desviaciones, se determinan las causas y se corrige lo que sea necesario.

QU ES EL ADMINISTRADOR DE PROYECTOS ?
El administrador de proyectos puede ser definido como el individuo que cumple con la tarea de integrar los esfuerzos
dirigidos hacia la ejecucin exitosa de un proyecto especfico. Esta persona enfrenta un conjunto de circunstancias nico en
cada proyecto.
El administrador de proyectos es una extensin del administrador general de una organizacin.
FUNCIONES DEL ADMINISTRADOR DE PROYECTOS
El administrador de proyectos opera independientemente de la cadena de mando normal dentro de la organizacin. Debe
dirigir y evaluar el proyecto; tambin planear, proponer e implementar polticas de administracin de proyectos, asegurar
la finalizacin del proyecto mediante compromisos contractuales.
Otras tareas que debe cumplir son desarrollar y mantener los planes del proyecto, darle una calendarizacin y
financiamiento adecuados al proyecto y evaluar y reportar su avance. Debe resolver los problemas a travs de decisiones
orientadas al objetivo. Adems, el administrador de proyecto debe resolver las siguientes preguntas:
* Qu se va a hacer ?
* Cundo se va a hacer ? Por qu se va a hacer ?
* Cunto dinero est disponible para hacerlo ?
* Qu tan bien se est haciendo el proyecto ?

IMPORTANCIA DEL ADMINISTRADOR DE PROYECTOS
La posicin del administrador de proyectos es importante porque las organizaciones modernas son muy complejas como
para excluir una administracin efectiva y ms especfica usando estructuras y relaciones organizacionales tradicionales.
Adems, esta persona provee el liderazgo necesario para que la cadena de proyectos fluya dentro de la red organizacional.
Definicin de proyecto.
Un proyecto es importante, un proyecto tiene que ejecutarse,, un proyecto incluye una descripcin de cmo ha de ser y cuanto ha de
costar el resultado esperado, un proyecto incluye un plan" y que "un proyecto es un trabajo".
Esto parece que se acerca ms a la idea que habitualmente tenemos del concepto de proyecto
Proceso nico que consiste en un conjunto de actividades, coordinadas y controladas, con fecha de inicio y trmino, que son
emprendidas para alcanzar un objetivo, que se establece de acuerdo con requisitos especficos, incluyendo restricciones de plazo,
coste y recursos.
Quizs sea una definicin demasiado formal, pero no podemos negarle la exactitud. Podemos argumentar que, en algunos proyectos, no
se establece una fecha de trmino ("lo antes posible", "para ayer"), y que en otros los requisitos distan mucho de ser "especficos".
Elementos de los Proyectos
Los elementos que componen la Ley Fundamental de los Proyectos son cuatro:
Funcionalidad
Plazo
Coste
Calidad
FUNCIONALIDAD
Llamar funcionalidad al conjunto de cosas que hace el sistema resultante del proyecto.
Es decir la lista de requerimientos o peticiones del usuario incluidas en el sistema. Por ejemplo, que registre
usuarios, que imprima tal informe, que compruebe el nmero de la tarjeta, que traiga caf... Esto incluye los
detalles; es decir, que imprima el informe en este conjunto de impresoras, con numeracin de pginas,
pudiendo cambiar el tipo de letra, que los botones sean redondos pero no mucho, con tonos suaves pero no
flojos... Por cierto, no se engae. Es imposible que un usuario defina hasta el ltimo detalle de lo que desea.
Fundamentalmente porque no lo sabe. Y si lo supiera, no sera capaz de expresarlo. Y si fuera capaz de
expresarlo, no seramos capaces de entenderlo. Y si furamos capaces de entenderlo, no conseguiramos
desarrollarlo exactamente como lo necesitaba. Y lo mismo ocurre con la calidad, tiempos de respuesta,
rendimiento, etc. Tendremos que encontrar la forma de trabajar con esa incertidumbre... y de tener xito en
estas condiciones.
PLAZO
Con plazo me refiero al tiempo que se emplea en desarrollar el sistema. OJO!, al tiempo que se emplea, no al
que se tarda, porque podemos tardar seis meses en programar una funcin, pero solo emplear una hora.
COSTE
El coste, hace referencia al trabajo necesario para desarrollar el proyecto. Este trabajo puede medirse en
horas/hombre, en dinero, recursos empleados, etc. No me estoy refiriendo al precio (lo que se paga). Un
patrocinador puede pagar un precio alto por un proyecto en el que no se realiza un trabajo acorde a dicho
precio. O por el contrario, es posible reducir el precio de un proyecto pagando menos al proveedor, pero no
podemos reducir el coste. Cuidado con los costes ocultos! Por ejemplo, podramos obligar a los
desarrolladores a hacer horas extras para cumplir una fecha de entrega. En ese caso, se incrementara el
trabajo, pero, si no se pagan las horas extra (como es habitual) parecer que el incremento de trabajo no tiene
coste!. Nada ms lejos de la realidad. El coste aparecer en forma de personas trabajando a disgusto (y eso es
mucho ms caro).
CALIDAD
La calidad es sin duda, el concepto ms escurridizo. Personalmente me gusta considerar la calidad como el nivel
de satisfaccin del usuario ante el sistema resultante del proyecto. Pero la calidad tiene dos partes. En primer
lugar, la ausencia de errores. Un sistema tendr ms calidad si falla menos. Por ejemplo, un usuario puede
solicitar el desarrollo de una pgina web. Eso es funcionalidad. Y el sistema resultante puede tener una
disponibilidad del 99%, dando error en un 1% de los accesos. Para algunos usuarios este nivel de disponibilidad
satisfacer sus expectativas, y para otros, no. En este mismo concepto de calidad se incluye el rendimiento.
Para algunos usuarios bastar con que el sistema atienda a un mximo de 100 usuarios con tiempos medios de
1 segundo. Otros en cambio, necesitarn atender 10.000 usuarios en ese tiempo. La segunda parte de la calidad
no es cuantificable, es cualitativa. Por ejemplo, un usuario puede considerar importante la facilidad de uso del
sistema. Incluso puede haberlo identificado como uno de los criterios de rendimiento del proyecto durante su
planteamiento.
Este criterio es difcilmente cuantificable, as que el grado de satisfaccin del usuario y, por lo tanto, la calidad
del sistema, sern "bastante subjetivos". Lo mismo puede aplicarse a otros conceptos habituales en los
proyectos, como el diseo grfico, la escalabilidad, la interoperabilidad, etc. Bien, ya tenemos los cuatro
elementos que componen la Ley Fundamental de los Proyectos, pero cul es la relacin entre ellos?
Relaciones
Vamos con un ejemplo. Supongamos que tenemos que desarrollar un proyecto para un sistema de contabilidad.
En cuanto a su funcionalidad, el sistema deber ser capaz de gestionar asientos contables, presentar balances y
cuentas de resultados, gestionar el plan contable, hacer liquidaciones de IVA... Tenemos previsto desarrollarlo
en un plazo de seis meses, con un equipo de 4 personas a dedicacin completa. Es decir, con un coste de 24
meses/hombre. Y en cuanto a la calidad... la de costumbre. Analicemos algunas relaciones: Por ejemplo, si
quisiramos reducir el plazo, podramos (en teora) incrementar el equipo de desarrollo. Si ponemos seis
personas, en lugar de cuatro, el plazo sera de cuatro meses, no?. Y en esa misma lnea, si ponemos 48, lo
haramos en quince das! "Nueve embarazadas no hacen un nio en un mes" Esta es una de las frases
habituales de los jefes de proyecto. Resulta evidente que no se puede reducir infinitamente el plazo de
ejecucin por muchos desarrolladores que se aadan al equipo. Este lmite se debe a dos factores, los
problemas de coordinacin y los cuellos de botella. En primer lugar, los problemas de coordinacin del equipo
de desarrollo son mayores cuanto mayor es el equipo. Y esta relacin no es precisamente geomtrica, sino
que se aproxima a una sucesin exponencial. En resumen, si coordinar un equipo de 25 desarrolladores
requiere 4 jefes de proyecto, un equipo de 50 requerir 16. Y si para dirigir a 4 jefes de proyecto basta un nico
director de proyectos, sern necesarios al menos cuatro para dirigir a dirigir a 16. Y cuatro directores jams se
pondrn de acuerdo. (Puede poner los nmeros que te resulten lgicos. Vers que la relacin no vara).
En segundo lugar, en todo proyecto existen cuellos de botella. De nada sirve incrementar el equipo con cuatro
programadores si el diseador grfico ya est trabajando doce horas al da. Pero curiosamente, el principal
cuello de botella suele pasar inadvertido. Es el usuario. A qu velocidad puede el usuario dirigir el proyecto? Y
estar seguro de que lo dirigir, si no es durante la ejecucin ser en la entrega o incluso despus, y entonces
los cambios... cuestan un ojo de la cara. Conclusin: todo proyecto tiene una relacin ptima entre plazo y
coste, que puede establecerse como el tamao del equipo ptimo de desarrollo. Por encima de esta relacin
ptima, es decir, ms gente en el equipo, solo se consigue incrementar los problemas de coordinacin y
saturar los cuellos de botella, pero no reducir el plazo. As que, para poder continuar con nuestro ejemplo,
vamos a suponer que el equipo de cuatro personas durante seis meses es "el ptimo". Aadir ms
desarrolladores no reducir el plazo. Y si incrementamos este slo conseguiramos tener ms tiempo libre (lo
cual no es necesariamente malo). Entonces... qu relaciones hay? Supongamos que variamos alguno de los
elementos y veamos qu pasa con el resto.
a) Incremento de Funcionalidad . Es decir, el usuario pide que el sistema haga ms cosas de las previstas. En
estas circunstancias hay dos opciones. Ser necesario realizar ms trabajo para incluir la nueva funcionalidad,
por lo que habr que incrementar el coste y, previsiblemente, el plazo. Pero tambin podemos reducir la
calidad del sistema, y de este forma, recortar de otras funciones el tiempo y el coste necesarios para desarrollar
la nueva funcionalidad.
b) Decremento de Funcionalidad . En este caso, la relacin es inversa. Ser necesario un trabajo menor para
completar el sistema, por lo que podemos reducir coste y plazo o, si preferimos, incrementar la calidad de otras
funciones.
c) Decremento del Plazo . Es decir, el patrocinador quiere que el proyecto concluya antes de lo previsto. En este
caso, solo tenemos una alternativa: No podemos incidir sobre el coste, porque si el proyecto est en su relacin
ptima, una reduccin de plazo conlleva obligatoriamente una reduccin de costes (sorprendente? S, pero
lgico). Ante una reduccin de plazo, estaremos obligados a reducir la funcionalidad y/o la calidad del sistema
para poder cumplir con el nuevo plazo.
d) Incremento de Plazo . De nuevo, la relacin inversa. Si disponemos de ms plazo, podemos incrementar la
calidad y/o la funcionalidad del sistema, en cuyo caso, tambin se incrementar el coste. Si por el contrario no
variamos ni la calidad ni la funcionalidad, tampoco se incrementar el coste. Aunque, evidentemente, el equipo
de desarrollo no tendr una dedicacin del 100% ni estaremos trabajando en esa "relacin ptima"
e) Incremento del Coste . Circunstancia poco comn ciertamente. Pero, si incrementamos el coste, podremos
realizar ms trabajo. En estas circunstancias, es posible desarrollar ms funcionalidad y/o incrementar la calidad
del sistema.
f) Decremento del Coste . Esto es mucho ms habitual, hay que reducir costes, y por lo tanto, realizar menos
trabajo. La nica forma de hacerlo, es reduciendo funcionalidad y/o calidad.
g) Incremento de Calidad . Es decir, el usuario quiere reducir la tasa de errores, o define con mayor detalle del
esperado algn aspecto del sistema. Para cumplir con las nuevas especificaciones, es necesario aumentar la
cantidad de trabajo, es decir, el coste del proyecto. Naturalmente, si incrementamos el coste (y siempre que el
proyecto est en su relacin ptima) se incrementar el plazo.
h) Decremento de Calidad . Obviamente, la situacin inversa. Permitir reducir el coste y el plazo.
Creo que despus de estos ejemplos, la relacin entre los cuatro componentes es clara. Con la premisa de que
el proyecto se encuentre en su "relacin ptima",
LAS VARIACIONES EN LA FUNCIONALIDAD Y/O LA CALIDAD AFECTAN DIRECTAMENTE AL PLAZO Y AL COSTE
Conviene destacar que plazo y coste NO SON INTERCAMBIABLES. No podemos incrementar uno sin incrementar
el otro si el proyecto est en esa "relacin ptima". Pero... si no lo est?
La Holgura del Proyecto
No es conveniente trabajar siempre en la "relacin ptima", a la mxima velocidad posible. Lo mismo les sucede
a los ciclistas profesionales, si ruedan al mximo de sus posibilidades, no podrn demarrar ni responder a los
ataques de sus adversarios. Hay que guardar fuerzas. En un proyecto, esta reserva de fuerzas se denomina
"holgura". Se trata de una provisin, en forma de plazo y coste, que permitir afrontar imprevistos. Por
ejemplo, si estimamos que nuestro proyecto de contabilidad requiere un mnimo de cuatro meses de trabajo en
condiciones ptimas (lo que supone un equipo de seis personas), podemos iniciar el trabajo con una previsin
de duracin de cinco meses y el mismo equipo de seis personas. De esta forma, tendramos una holgura de
cuatro meses/hombre de coste (4/24 = 16%).
Cmo podemos saber la holgura que necesita un proyecto? Es difcil, la experiencia suele ser la mejor
consejera, pero s es fcil saber de qu depende. Los proyectos tienen Riesgo, probablemente por eso son
proyectos y no trabajos rutinarios. Pues cuanto ms arriesgados sean, ms holgura necesitarn.

El Riesgo
El riesgo es la diferencia entre las ecuaciones fsicas y nuestra ley fundamental de proyectos. Una ecuacin fsica
siempre se cumple. Pero nuestra ley fundamental no. Si tenemos un proyecto con una determinada
funcionalidad y un nivel de calidad conocido, podramos, si nuestra ley fuera una ecuacin matemtica, calcular
con precisin el plazo y el coste que les corresponden. Pero todos sabemos que as como los cuerpos caen en La
Tierra con una aceleracin de 9,8 m/s2, los proyectos de software no suelen ser tan precisos. Todo lo que pueda
ocurrir, que modifique nuestra ley fundamental, lo consideraremos Riesgo Hay, sin duda, infinidad de
circunstancias y factores que pueden afectar a un proyecto: problemas con la tecnologa, bajas del personal,
prdidas de cdigo, falta de experiencia, problemas personales e incluso terremotos... Y todos ellos afectan al
proyecto. Pero tambin es cierto que todos ellos se quedan pequeos frente a los dos factores fundamentales
de riesgo en los proyectos actuales, los Errores y los Cambios. Los Errores son Inevitables: Quizs haya tenido
ocasin de leer "El Principio de Dilbert". Por debajo de unos fantsticos chistes sobre informticos, Dilbert
enuncia un principio sorprendente..."Todos somos idiotas" Y nos equivocamos. Y sin embargo, y aqu est la
idiotez, actuamos como si eso no fuera a ocurrir nunca! Me explico. En el mundo de los proyectos tecnolgicos,
todava hay muchsimos profesionales, que creen en la "Fase de Diseo". Es ms, son la mayora. Qu es la
"Fase de Diseo"? Es una fase que se ejecuta en las primeras fechas de un proyecto. Y cuyo objetivo consiste en
"capturar" los requerimientos del usuario y definir la arquitectura interna del sistema.
El problema es que esto se hace (tericamente) sin desarrollar nada. El resultado de "La Fase de Diseo" es ...
un simple documento! Sinceramente, no conozco a nadie capaz de "imaginarse" y poner por escrito una
aplicacin sin realmente programarla primero. De hecho, reconozco que yo no soy capaz ni siquiera de hacer el
diseo de las aplicaciones que ya he realizado. Mucho menos de una que no he programado an. En un diseo,
se cuelan errores de tres tipos:
Errores del usuario, que como nunca ha visto lo que espera del proyecto, no se lo imagina bien.
Errores del Analista, que como nunca ha hecho un proyecto igual, no sabe describirlo con precisin.
Errores de Entendimiento. Que se producen cuando el analista no entiende bien lo que le dice el usuario (o
viceversa).
Si ha esto aadimos la facilidad con que se quedan obsoletos los diseos incluso antes de que concluya el
desarrollo del proyecto y el alto coste que tiene su modificacin, concluimos que "La Fase de Diseo" es ... UN
ERROR MONUMENTAL. Claro, que si tienes analistas que nunca se equivocan, usuarios que saben
perfectamente lo que quieren y tus proyectos no estn inmersos en entornos de cambio, pues puedes hacer
Diseos. Incluso es divertido. Pero si no es as, y asumiendo que tanto el usuario como los desarrolladores son
humanos y cometern errores, no crees que es ms lgico reconocer que habr errores y actuar en
consecuencia?
El Cambio es Necesario
Los Cambios en un proyecto destrozan las previsiones, invalidan los planes y hacen intil parte del trabajo
realizado. Un usuario, que en mitad de un proyecto cambia alguna especificacin pone en grave riesgo la
viabilidad del proyecto. Y sabes una cosa?, un desarrollador que no acepta cambios en un proyecto, convierte
en intil el trabajo realizado. Lo repito, CONVIERTE EN INTIL EL TRABAJO REALIZADO.
Los Cambios no slo son necesarios, adems son buenos! Consiguen que el proyecto siga teniendo valor para
el patrocinador, hacen que el resultado final se adapte perfectamente a sus necesidades, incluso aunque estas
hayan cambiado desde el inicio del proyecto. Un proyecto que no cambia, es un proyecto muerto Pero as
como es innegable la ventaja que supone aceptar (e incluso provocar) los cambios en un proyecto, tambin es
innegable que los cambios traen problemas. Pueden suponer prdida del trabajo ya realizado, obligan a rehacer
planes y previsiones e incluso pueden frustrar al equipo de desarrollo. Entonces... cmo los tratamos?
Gestin del Riesgo
Slo tu forma de trabajo, tu mtodo puede ayudarte a gestionar el riesgo. Si adems estandarizas esta forma
de trabajo y la documentas, podrs ir mejorndola con el tiempo, aadiendo tu experiencia. Pero... Qu puede
incluir un procedimiento para la gestin de proyectos que ayude a gestionar el riesgo? Analicemos con detalle
las dos fuentes de riesgo.
A) GESTIN DE ERRORES
Vamos con los errores. Cul debe ser nuestro objetivo respecto a los errores? No te confundas! NO
QUEREMOS EVITARLOS. No podemos invertir nuestro esfuerzo en intentar evitar los errores, SON INEVITABLES.
Todos cometemos errores. El usuario se equivocar, los desarrolladores se equivocarn, e incluso el jefe de
proyecto cometer errores. Entonces... qu queremos hacer con ellos? Pues necesitamos un mtodo de
trabajo que nos permita CORREGIRLOS CUANTO ANTES.
Corregir un error a los pocos minutos de haberlo cometido suele tener un coste miles de veces inferior al de
corregirlo tras varios meses. Corregir cuanto antes, ese es nuestro objetivo. Cmo lo hacemos? Ahora vamos a
empezar a definir uno de los aspectos de nuestro mtodo de trabajo.
1.- Identificar el Error
Para poder corregir un error necesitamos, primero encontrarlo. En consecuencia, hay que hacer pruebas. Y
como queremos encontrarlo cuanto antes, hay que hacer pruebas frecuentes, muy frecuentes, muy muy muy
frecuentes. No olvides que, cada minuto que pasa sin que encuentres el error, el coste de su correccin sube,
sube, sube y sube... Te ests obsesionando con esto? Bien.
Dos cosas respecto a las pruebas. Primera, TODOS COMETEMOS ERRORES, as que no pruebes solo el trabajo de
los desarrolladores. El usuario tambin comete errores y hay que encontrarlos. T, como jefe de proyecto,
tambin cometers errores, y tendrs que encontrarlos... cuanto antes.
Segunda, no te imaginas lo que CUANTO ANTES puede significar. Con qu frecuencia puedes probar cada
aspecto de un proyecto? Redcelo a la mitad y vuelve a empezar! Ms adelante hablaremos de metodologas
giles. Realmente no te imaginas con que frecuencia pueden probarse las cosas.
2.- Valorar el Error
De un error hay que valorar dos cosas: qu valor resta al proyecto? Y cul es el coste de su correccin?
3.- Decidir sobre su Correccin.
Merece la pena corregirse? A veces, hay errores cuya correccin supondra un gran trabajo y aportaran muy
poco valor. Si es as, djalos. Ten en cuenta que este tipo de decisiones sobre el valor y el coste corresponden al
patrocinador, quien deber estar asesorado por su Analista de Viabilidad.
4.- Planificar su Correccin
Si la decisin es corregirlo, el jefe de proyecto deber establecer cundo y quien corrige el error. De este modo,
la correccin del error se convierte en una accin ms del} proyecto y quedar bajo las actividades del control
de ejecucin.
B) GESTIN DE CAMBIOS
Y los cambios? Los cambios no son iguales que los errores, pero se parecen mucho. Nuestro objetivo con los
cambios tampoco es evitarlos. SON INEVITABLES. Pero al contrario que con los errores, queremos provocarlos.
Los necesitamos para que el proyecto gane valor. Cuanto ms se adapte a las necesidades del usuario, ms
valor tendr para l. As que, con los cambios, nuestro objetivo debe ser PROMOVERLOS CUANTO ANTES.
Cuanto antes, es conveniente, porque al igual que con los errores, los cambios, cuanto antes se realcen, menor
coste tendrn.
.