¿Qué es un proyecto?Las organizaciones trabajan. El trabajo generalmente involucra operaciones oproyectos, aunque las dos ...
•Implementar un nuevo procedimiento o proceso en un negocio.Carácter TemporalTemporal quiere decir que cada proyecto tiene...
propósito de desarrollar el proyecto, y el equipo es desmantelado y sus miembrosreasignados cuando el proyecto se termine....
realizar - deberá mantenerse constante aún en la luz del cambio las característicasdel producto que sea progresivamente el...
o, por la concepción errónea de que quitan tiempo), primando las actividadesmeramente técnicas. De poco valen los esfuerzo...
Responder a este simple pregunta no es tan fácil como pueda parecer a simplevista, y prueba de ello es la diferencia de op...
   Capacidades Humanas. Habilidades que permitan trabajar con personas    (comunicación, trabajo cooperativo,…).   Capac...
¿Tenemos claro cuál es la función de un Jefe de Proyecto?En los distintos cursos de gestión de proyectos que he impartido ...
de Proyecto) sean desempeñados por la misma persona, cosa por otro lado muynormal en las pequeñas empresas, donde prima el...
Esta nueva forma de dirección nos llevará a entornos laborales más flexibles,dinámicos y estructuras organizativas mucho m...
Seguro que esa frase la hemos oído todos en algún momento. Esa o una de susvariantes: era un buen técnico, pero pésimo jef...
Por todo esto, tanto las organizaciones como los propios profesionales,deberíamos ser conscientes que la evolución hacia u...
continuación se describen las actividades más importantes dentro de cadadivisión:Formación.      Categoría A. Cursos ofer...
   Después del 1 de Marzo de 2011, se deberá reportar cualquier PDUs    obtenido que no hayan sido registrado usando las ...
Hasta aquí el cambio pero, y valga la redundancia, ¿hay algún pero? Al principiome pareció un error limitar el número máxi...
total/integral del proyecto (accountability). Entre sus funciones principales hay quedestacar:      Se dedica al proyecto...
La Gestión de Proyectos como Pilar de la CalidadSiempre hablamos de Calidad y, la mayoría de las veces, nuestro entendimie...
7. Es importante saber manejar los conflictos (siempre habrá: con el equipo, conotros departamentos, incluso con el client...
Estas son las conclusiones de la pequeña encuesta:Microsoft Project es la herramienta de planificación más utilizada.    ...
de tareas y fechas), cuando realmente es un potente gestor (exagerando un      poco podríamos decir que es un pequeño ERP)...
experimentar con nuevas tecnologías, herramientas o arquitecturas). Muchoshemos tenido esa "deformación" profesional (y me...
perspectivas, incluso la económica, y que los interlocutores nos comprendan. Porello tenemos que familiarizarnos con térmi...
Principales causas del fracaso de los proyectosNo es fácil enumerar las razones por las que fracasan los proyectos y el mo...
   La falta de definición de roles y responsabilidades. Es imprescindible que al       principio del proyecto quede clara...
percepciones del usuario: la aplicación, el producto entregable, puede funcionarcorrectamente pero no satisfacer al usuari...
El término administración de proyectos es a veces usado para describir unaaproximación organizacional a la administración ...
Las Áreas de Conocimiento de la Administración de ProyectoParte II, las Áreas de Conocimiento de la Administración de Proy...
fue desarrollado. Consiste en la planeación de la calidad, a seguranza de lacalidad, y control de calidad.Capítulo 9, Admi...
describe aspectos claves del contexto de la administración de proyectos, que noestán descritos en otras partes de este doc...
si el proyecto debe continuar a su próxima fase y (b) detectar y corregir errores demanera eficiente. Estas revisiones de ...
de la fase anterior cuando los riesgos involucrados se tornan aceptables. Estatáctica de traslapo de fases muchas veces es...
Se debe tener cuidado para distinguir entre el ciclo de vida del proyecto y el ciclode vida del producto. Por ejemplo, un ...
Upcoming SlideShare
Loading in …5
×

Definicion de proyecto

6,188 views

Published on

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
6,188
On SlideShare
0
From Embeds
0
Number of Embeds
3
Actions
Shares
0
Downloads
55
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Definicion de proyecto

  1. 1. ¿Qué es un proyecto?Las organizaciones trabajan. El trabajo generalmente involucra operaciones oproyectos, aunque las dos se puedan traslapar. Las operaciones y los proyectoscomparten muchas características; por ejemplo, ellas son:•Desarrolladas por personas.•Limitadas por recursos escasos.•Son planeadas, ejecutadas, y controladas.Las operaciones y los proyectos difieren principalmente en que las operacionesson sucesivas y repetitivas mientras que los proyectos son temporales y únicos.Un proyecto por lo tanto puede ser definido en término de sus característicasdistintivas— un proyecto es una tarea temporal desarrollada para crear unproducto o servicio único. Temporal quiere decir que cada proyecto tiene uncomienzo definitivo y una terminación definitiva. Único quiere decir que el productoo servicio es diferente de alguna manera distintiva de todos los proyectos oservicios similares.Los proyectos son desarrollados en todos los niveles de la organización. Estospueden involucrar a una sola persona o a muchas miles. Y pueden requerir menosde 100 horas para completarse o más de 10,000,000. Los proyectos puedeninvolucrar a una sola unidad de una organización o cruzar muchas fronterasorganizacionales como en consorcios o sociedades de hecho. Los proyectos sonmuchas veces componentes críticos de la estrategia de negocios de laorganización que los desarrolla. Ejemplos de proyectos pueden incluir:•Desarrollar un nuevo producto o servicio.•Efectuar un cambio de estructura, de personal, o de estilo en una organización.•Desarrollar un nuevo vehículo de transporte.•Desarrollar o adquirir un nuevo sistema de información.•Construir o desarrollar una construcción.•Administrar una campaña electoral.
  2. 2. •Implementar un nuevo procedimiento o proceso en un negocio.Carácter TemporalTemporal quiere decir que cada proyecto tiene un comienzo definitivo y unaterminación definitiva. El fin es alcanzado cuando los objetivos del proyecto hansido alcanzados, o cuando se hace claro que todos los objetivos no pueden seralcanzados y que el proyecto tiene que ser terminado. Temporal no quiere decirnecesariamente corto en duración; muchos proyectos duran varios años. En cadacaso, sin embargo, la duración del proyecto es finita; los proyectos no sonesfuerzos sucesivos.Adicionalmente, el término temporal no se aplica generalmente al producto oservicio creado por el producto. Muchos proyectos son desarrollados para crear unresultado duradero. Por ejemplo, un proyecto para crear un monumento nacionalcreará un resultado que se espera dure por varios siglos.Muchos desarrollos son temporales en el sentido en que van a terminar en algúnpunto del tiempo. Por ejemplo, el trabajo de ensamble en una planta automotriz vahacer eventualmente discontinuado, y la planta en si abandonada. Los proyectosson fundamentalmente diferentes porque el proyecto cesa cuando sus objetivosdeclarados han sido obtenidos, mientras que los desarrollos de no proyectosadoptan una serie nueva de objetivos y continúan trabajando.La naturaleza temporal de los proyectos se pueden aplicar a otros aspectos deldesarrollo tales como:•La oportunidad de la ventana de mercado es usualmente temporal — La mayoríade los proyectos tienen un marco de tiempo limitado en el que tiene que producirsu producto o servicio.•El equipo de proyecto, como un equipo, rara vez dura más que el proyecto— lamayoría de los proyectos son desarrollado por un equipo creado con el sólo
  3. 3. propósito de desarrollar el proyecto, y el equipo es desmantelado y sus miembrosreasignados cuando el proyecto se termine.Producto o Servicio ÚnicoLos proyectos involucran hacer algo que no se ha hecho antes, por lo tanto, esúnico. Un producto o un servicio pueden ser únicos aunque la categoría a la quepertenezca sea grande. Por ejemplo, muchos miles de edificios de oficina han sidodesarrollados, pero cada edificio en si es único — de distinto dueño, de distintodiseño, diferente locación, y diferentes contratistas, y así etc. La presencia deelementos repetitivos no cambia fundamentalmente la característica de ser único.Por ejemplo:•Un proyecto para desarrollar una vía comercial puede requerir múltiples prototipos•Un proyecto para introducir una nueva droga al mercado puede requerir de milesde dosis durante las pruebas clínicas.•Un proyecto de desarrollo de bien raíz puede incluir cientos de unidadesindividuales.Debido a que el producto de cada proyecto es único, las características quedistinguen el producto o servicio deben ser elaboradas progresivamente.Progresivamente quiere decir "Procedimientos en pasos; avance continuo porincrementos" mientras que elaborados quiere decir "trabajado con cuidado aldetalle; desarrollado enteramente”. Las características distintivas serán definidasde manera amplia, temprano en el proyecto y erán cada vez más y más explícitasy detalladas a medida que el equipo del proyecto desarrolla un entendimientomejor y más completo del producto.La elaboración progresiva de las características de un producto debe sercuidadosamente coordinada en concordancia con una apropiada definición delalcance del proyecto, particularmente si el proyecto es desarrollado bajo uncontrato. Cuando definida propiamente, el alcance del proyecto - el trabajo a
  4. 4. realizar - deberá mantenerse constante aún en la luz del cambio las característicasdel producto que sea progresivamente elaborado.Ejemplo. Una planta procesadora química empieza con un proceso de ingenieríapara definir las características de un proceso. Estas características serán usadaspara diseñar las unidades de procesamiento principales. Esta información seconvierte en la base del diseño de ingeniería que definirá tanto el detalle de layoutde la planta y de las características mecánicas de las unidades de proceso yfacilidades auxiliares. Todo esto resulta en los dibujos de diseño que seránelaborados para producir dibujos de fabricación (isométricos de construcción)durante la construcción, habrán interpretaciones y adaptaciones que serán hechasa medida que se necesiten y estarán sujetas a una aprobación formal. Estaelaboración adicional de las características es capturada por un dibujo "as built".Durante los ensayos y entrega, un desarrollo adicional de las características esmuchas veces hecho en la forma de ajustes operacionales finales. Los clientes y la gestión de proyectosEn algunas ocasiones, a la hora de ejecutar un proyecto, nos podemos encontrarcon personas, equipos dentro de algunos clientes que a la hora de ejecutar unproyecto no valoran lo suficiente las actividades de gestión dentro del proyecto.Esto supone un problema ya que, por desgracia, la gestión suele ser, junto con lasactividades de calidad, una de las principales afectadas por recortes (presupuesto
  5. 5. o, por la concepción errónea de que quitan tiempo), primando las actividadesmeramente técnicas. De poco valen los esfuerzos que puedan hacer las empresasproveedoras de servicios para mejorar las actividades de gestión entre susprofesionales, si es el propio cliente el que no valora dicha función, y no esconsciente o no percibe el valor que aporta al proyecto. Por eso creo que las empresas y profesionales que desarrollan su actividad dentro del ámbito de la gestión de proyectos tienen que ser conscientes que también deben “formar” y concienciar a sus clientes, hacerles entender la importancia de la gestión, del proceso de gestión, como pieza fundamental (necesaria aunque no suficiente) para minimizar el riesgo de fracaso en los proyectos. Y esa función de “concienciación” y “formación” se tiene que hacer con responsabilidad, sin excesos y haciendo ver (de forma cuantitativa y no solo con buenas palabras) los beneficios que ha aportado al proyecto dicha gestión. A veces incluso esa labor de pedagogía se alarga en el tiempo, y no se consigue el propósito rápidamente, en el primer proyecto, pero no por ello se debe desistir. Gestionar Proyectos: ¿Arte o Ciencia?
  6. 6. Responder a este simple pregunta no es tan fácil como pueda parecer a simplevista, y prueba de ello es la diferencia de opiniones que podeis encontrar en la red:desde los que apuestan por ciencia con el argumento de que incluye existentécnicas, herramientas, y procesos que nos ayudan a la labor, hasta los queapuesta por el arte debido a las interacciones que un jefe de proyecto tiene quetener con los stakeholders de un proyecto -clientes, proveedores, los gestores,etc...Para dar respuesta a esta pregunta vamos a echar un ojo a las responsabilidadesque debe tener un buen jefe de proyecto: Asegurar que todos los hitos y resultados sean alcanzados cumpliendo las restricciones de tiempos, costos y respetando los estándares de calidad. Alcanzar los objetivos contractuales. Trabajar conjuntamente con los Responsables Funcionales para asegurar que los recursos se empleen en forma eficaz y eficiente. Actuar como el punto principal de comunicación entre el cliente (externo), patrocinador, la alta dirección y las direcciones funcionales (internos). Preparación de planes realistas. Mantener informados a stakeholders en forma completa. Tomar todas las decisiones necesarias, ya sean para alternativas o para la terminación. Proponer o iniciar acciones correctivas. Responsabilidad final total. Resolver todos los conflictos, si es posible.Para poder responder con éxito a dichas responsabilidades, un Director deProyecto tiene que tener o adquirir una serie de capacidades y habilidades, que sepueden catalogar de la siguiente forma: Capacidades Técnicas. Conocimiento de procedimientos, métodos y procesos.
  7. 7.  Capacidades Humanas. Habilidades que permitan trabajar con personas (comunicación, trabajo cooperativo,…). Capacidades Conceptuales y de Diseño. Capacidad de entender el entorno, analizarlo y adaptarse.Con este planteamiento, la dirección de proyecto se puede considerar una ciencia,ya que se basa en métodos, procesos, datos empíricos, aunque sin embargo noes un factor suficiente ya que se necesitan una serie de habilidades sociales.Entonces, ¿como definiriamos la Dirección de Proyectos? Después de muchobuscar/leer, la definición con la que me encuentro más cómodo se resumen enesta frase: Gestionar un proyecto es un Arte que se basa en conocimientos CientíficosDecimos que es un “arte” puesto que las decisiones no están unívocamentedeterminadas por cada situación (cada proyecto varía significativamente enfunción del entorno, con lo que podríamos aplicar la fase de José Ortega y Gasset:“Yo soy yo y mi circunstancia”) y utilizamos el término “ciencia” puesto que eldirector de proyecto debe utilizar todas las experiencias, procesos, herramientas ytécnicas conocidas y científicamente válidas.En resumen, para ser un buen Director de Proyecto no sólo es necesario aprender(o chapar) una serie de técnicas o usar unas buenas herramientas, es condiciónnecesaria pero no suficiente. Para dirigir correctamente un proyecto necesitamosuna serie de habilidades y experiencias que nos ayuden a la interacción con elentorno.
  8. 8. ¿Tenemos claro cuál es la función de un Jefe de Proyecto?En los distintos cursos de gestión de proyectos que he impartido el perfil de losasistentes siempre ha sido el mismo: profesionales, consultoras o proveedores deservicios de distintos sectores que tienen un creciente interés en mejorar susconocimientos y técnicas relacionadas con la gestión de proyectos. A pesar de losesfuerzos por parte de todos, y que en el último año (quizá por el propio efecto dela crisis) se ha incrementado notablemente el interés por mejorar en todo lorelacionado con la gestión, todavía queda mucho camino por recorrer.Los profesionales y las empresas tienen que ser conscientes de lo que significaser Jefe/Director de Proyecto: no es un simple jefe o coordinador técnico de losequipos de trabajo, es mucho más. Sin embargo, y a la vista de algunas ofertas deempleo, parece que no todo el mundo entiende cual es el rol de un Director (Jefe)de proyecto. ¿por qué digo esto? Según PMBok® el Director de Proyecto es unapersona donde reside la responsabilidad del proyecto, con dedicación al proyectoen sí en lugar de aspectos técnicos, pero viendo algunas ofertas de empleo notodo el mundo tiene tan claro esta función: “se busca jefe de proyecto Java/J2EE”,“se busca jefe de proyecto .Net”,... No es que diga que el Jefe de Proyecto notenga que tener una base técnica, ya que considero imprescindible que entienda elentorno en el que se desarrolla su proyecto, pero su función trasciende esosaspectos. Ojo, hablamos de roles, otra cosa es que distintos roles (Analista, Jefe
  9. 9. de Proyecto) sean desempeñados por la misma persona, cosa por otro lado muynormal en las pequeñas empresas, donde prima el hombre orquesta. Creo queuno de los problemas es que muchas veces se confunde el Jefe de Proyecto conel perfil de un Jefe/Coordinador Técnico donde priman mucho más losconocimientos técnicos, y en un proyecto hay que prestar atención a los aspectostécnicos, pero también a otros aspectos mas relacionados con la perspectiva denegocio, que necesita otras habilidades.>Por esto tenemos que seguir reforzando el rol de Director de Proyecto en lasempresas, dándole valor, en resumen, PROFESIONALIZAR LA GESTIÓN DEPROYECTOS. Hacia un cambio de modelo: de Jefe de Proyecto a Lider de ProyectoTradicionalmente nos referimos a ese perfil de Responsable/Coordinador comoJefe de Proyecto y, tras esa denominación existe, subyacente, toda una cultura decómo se estaba dirigiendo los equipos tradicionalmente. La acepción de Jefe tieneuna connotación de mando/autoridad impuesta que, si bien podía funcionar enentornos más industriales, en una sociedad como la actual, basada en elconocimiento, no tiene tanta cabida. Las empresas actuales no necesitan tantos"controladores", más bien necesitan facilitadores, líderes que ayuden a los equiposa alcanzar el objetivo común: el éxito en la actividad o proyecto.
  10. 10. Esta nueva forma de dirección nos llevará a entornos laborales más flexibles,dinámicos y estructuras organizativas mucho más planas, sin tantos mandosintermedios y donde las personas tienen que ser capaces de asumir una mayorresponsabilidad.Este modelo encaja perfectamente con la visión de proyecto donde un Líder deProyecto (remarco la palabra Líder frente a Jefe o Director) es el encargado decoordinar los distintos engranajes que conforman el proyecto, haciendo defacilitador que ayuda a resolver conflictos, guía al equipo, ayuda a resolverincidencias, sirve de interlocutor (de paraguas) con personas ajenas al equipo(clientes, proveedores, responsables de la organización,...), cohesiona el propioequipo y le aporta una visión global del conjunto del proyecto. En estos ambientescobra especial relevancia la comunicación, el feedback (retroalimentación), lamotivación, la escucha activa... en definitiva HACER EQUIPO.Sin embargo, para que esto sea posible, todavía nos queda mucho camino porrecorrer en cuanto a formación en las propias organizaciones y de los propiosempleados, y se hace cada vez más necesario orientarnos hacia un sistemabasado meritocracia, el esfuerzo y la responsabilidad. Aquí os dejo el enlace al artículo de Expansión: ¿Es mejor un mundo sin jefes? Era un buen albañil, pero pésimo capataz: no es lo mismo técnico que gestor
  11. 11. Seguro que esa frase la hemos oído todos en algún momento. Esa o una de susvariantes: era un buen técnico, pero pésimo jefe de proyecto; o era una buenaenfermera, pero una pésima jefa de enfermeras. Todas esas frases tienen comotrasfondo una mala práctica que está muy implantada en una sociedad como lanuestra, donde la única forma de progresar salarialmente en muchas profesioneses "subir en el escalafón" sin tener en cuenta las habilidadespersonales/profesionales (esto pasa mucho en profesiones tecnológicas). En esahuida hacia adelante, llena de buenas intenciones para poder promocionar altrabajador, en muchas ocasiones, quizá demasiadas, obtenemos el efectocontrario al deseado, causando mucho daño, tanto al propio trabajador, como a laempresa y a los compañeros. Porque al final, un buen trabajador, a base de"empujones" en el escalafón, puede acabar convirtiéndose en un trabajadorineficiente. O dicho de otro modo: "Un profesional podrá seguir ascendiendo hastaalcanzar su nivel máximo de incompetencia".Las causas por la que ocurre esta mala práctica son muchas: cultural, planesprofesionales excesivamente rígidos, mal entendimiento de lo que es unaevolución profesional, etc... Pero en el fondo lo que hay es una mala comprensiónde lo que es ser un Jefe de Proyecto. Las habilidades que tienen que tener todoJefe (ya hablemos de jefatura de proyecto, gerente, coordinador,...) son distintas alas que tiene que tener un técnico, y eso es debido a las nuevas funciones que setienen que asumir, porque no es lo mismo ejecutar que delegar la ejecución. UnJefe de Proyecto tiene que saber combinar las habilidades técnicas de suprofesión, con un mayor peso de las habilidades humanas (comunicación,negociación, liderazgo, ...) a medida que aumenta se nivel de responsabilidad. Alfinal un Jefe de Proyecto, o un responsable, o un coordinador (como queráisllamarlo) es un profesional cuya función principal se tiene que centrar en el propioproyecto más que en los aspectos funcionales o técnicos del mismo. En un postanterior "Las habilidades de un buen Director de Proyecto", ya presentaba cualesson las habilidades que tiene que tener un buen Jefe de Proyecto, comoCapacidad de comunicación y liderazgo.
  12. 12. Por todo esto, tanto las organizaciones como los propios profesionales,deberíamos ser conscientes que la evolución hacia un perfil gestor es un pasomuy importante, que se tiene realizar después de asegurarnos que poseemos lashabilidades y la formación necesarias para cumplir nuestro nuevo cometido. Y,complementariamente, deberíamos promocionar los buenos técnicos dentro delpropio perfil, y permitir desarrollar su carrera profesional dentro de las funcionestécnicas, sin obligar a dar el salto a la gestión para poder progresareconómicamente, porque si hacemos eso, es muy probable que todos perdamos yllegue la desmotivación.PMI publica las nuevas categorías para obtener PDUs dentro del programa CCRRecientemente, PMI (Project Management Institute) ha comunicado los cambiosque van a producirse en las categorías de PDU (Professional Development Units)para la renovación de la certificación PMP, dentro del programa CCR (ContinuingCertification Requirements).El cambio viene derivado, principalmente y según detallan en el anuncio enviado alos asociados, por la complejidad del modelo anterior (basado en una estructurade 5 categorías) que se reflejó en un estudio realizado por el propio instituto. Elcambio propuesto consiste en una simplificación mediante la agrupación en 2grandes divisiones: Formación (sin número máximo de PDUs) y Contribución a laProfesión (con un máximo de PDUs en cada ciclo de certificación -3 años-). A
  13. 13. continuación se describen las actividades más importantes dentro de cadadivisión:Formación.  Categoría A. Cursos ofertados por proveedores registrados de PMI (PMIs R.E.P.), o ofertados por comunidades o capítulos.  Categoría B. Educación continuada, ofertada por Universidades, instituciones no registradas como proveedores PMI o por profesionales o miembros de la asociación.  Categoría C. Auto-Formación a través de libros, artículos, videos, etc.Contribución a la profesión.  Categoría D. Crear nuevos conocimientos en gestión de proyectos, mediante la elaboración de artículos, libros, orador en seminarios-talleres, etc...  Categoría E. Servicios de voluntariado no remunerado como trabajo en la elaboración de algún estándar, participando como miembro de una asociación, o en la organización de un congreso, etc..  Categoría F. Trabajar como profesional en gestión de proyectos (experiencia demostrable como jefe de proyectos). Al parecer, estas nuevas divisiones y sus categorías han sido valoradaspositivamente: un 82% de los encuestados están satisfechos con las nuevascategorías propuestas y un 76% piensa que será más positivo.La nueva Estructura de Categorias empieza a implantarse a partir del 1 de Marzode 2011. Antes de esta fecha, teneis que tener en cuenta los siguientes pasos:  Registrar los PDUs obtenidos en el sistema CCR bajo las categorias actuales.
  14. 14.  Después del 1 de Marzo de 2011, se deberá reportar cualquier PDUs obtenido que no hayan sido registrado usando las nuevas categorias. Durante esta transición no se perderá ningún PDU.
  15. 15. Hasta aquí el cambio pero, y valga la redundancia, ¿hay algún pero? Al principiome pareció un error limitar el número máximo de PDUs en la categoría decontribución a la profesión, ya que, si compartir experiencias es la mejor forma deaprender y promocionar la profesión, ¿por qué limitar el número de PDUs?Posteriormente, y tras una breve reflexión, creo que para continuar avanzandoindividualmente en la profesión, sí que es necesario potenciar dos aspectos base:formación y experiencia. Estas son, precisamente, las nuevas categorías delprograma de certificación continua. Sin embargo, es aqui donde encontré unainconsistencia en el nuevo modelo de categorías: si para renovar la certificaciónno podemos centrarnos solo en la contribución a la profesión (con seminarios,artículos, ...) y nos obligan, de algún modo, a formarnos (obtener 15 PDUs en ladivisión de formación), ¿por qué si que puedo renovar las credenciales (PMP,PMI-SP, PgMP,...) sólo con acciones formativas y sin niguna contribución y/oexperiencia demostrable? Si PMI propone que obtener las credenciales es tenerun compromiso con la profesión, para renovarla debería ser necesario obtenerPDUs de las dos categorías para poder renovar las credenciales (por ejemplo conuna relación 1/3 entre formación y experiencia/contribución). Aunque puedaresultar difícil aportar artículos, o impartir sesiones formativas o realizar accionesde voluntariado (categorias D y E), ya que estas actividades puede que no estén alalcance de todos, la categoría F nos permite obtener PDUs mediante el "trabajocomo profesional en gestión de proyectos". De esta forma no sería unimpedimento poder obtener PDUs de las dos categorías: un profesional quedemuestre su actividad como Jefe de Proyecto y demuestre que sigue formándose(con un cursos formales o auto-estudio) podría obtener los PDUs necesarios pararenovar las credenciales. Las habilidades de un buen Director de ProyectoSegún la definición de PMBok (Project Management Body of Knowledge), el Jefede Proyecto (Director de Proyecto) es la persona que tiene la responsabilidad
  16. 16. total/integral del proyecto (accountability). Entre sus funciones principales hay quedestacar:  Se dedica al proyecto en sí y no a los aspectos funcionales del proyecto  Se encarga de la coordinación de los integrantes del equipo de proyecto  Utiliza de forma apropiada e integral las actividades de planificación y control  Es el responsable de asegurar que todos los hitos y objetivos se alcancen  El punto principal de comunicación, tanto hacia el equipo, como hacia los clientes y proveedores (en definitiva, stakeholders)  Tomar las decisiones necesarias y proponer acciones correctivas  Para poder hacer todo ello, el Director de Proyecto tiene que tener una serie de habilidades muy concretas:  Liderazgo  Capacidad de comunicación  Capacidad de Negociación  Capacidad de resolución de conflictosPor último, y no menos importante, tiene que ser capaz de mantener el foco delequipo en el objetivo final del proyecto. A lo largo de la vida de todo proyectosiempre surgirán problemas y situaciones difíciles que pueden desmoralizar alequipo, sobre todo en proyectos complejos. Por eso creo que un buen Director deProyecto tiene que ser un poco psicólogo y tener la capacidad de sobreponerse asus frustraciones y ser capaz de motivar al equipo. La motivación, algo queestamos cansados de oír en diversos ámbitos (entrenadores deportivos, ...) peroes una capacidad muy difícil de encontrar, una "rara avis", pero que no debemosperder de vista. La mejor forma de motivar es "empatizar" con el equipo, darejemplo, y focalizarse en pequeños objetivos a corto plazo, que nos permitanmantener al equipo "alerta" y alineados y concienciados con la consecución delobjetivo final que perseguimos.
  17. 17. La Gestión de Proyectos como Pilar de la CalidadSiempre hablamos de Calidad y, la mayoría de las veces, nuestro entendimientode la calidad se circunscribe al producto sin defectos. Sin embargo, calidad esalgo más que hablar de cero defectos. Calidad es que nuestro producto cumpla lasexpectativas del cliente y ahí, en las expectativas, está lo realmente difícil porque,muchas veces, las expectativas son claras pero en otras ocasiones, no tanto: sonlo que se llaman expectativas implícitas. Y ¿cómo hacemos para asegurar lacalidad en nuestros productos/servicios? La respuesta no es sencilla, pero creoque un buen proceso de Gestión de Proyectos nos puede ayudar en esa labor.Tenemos que ser conscientes que la Gestión de Proyectos es una piezafundamental a la hora de ofrecer un buen producto/servicio, y por ello tenemosque profesionalizar la gestión, darle valor (sobre todo en un mercado como eltecnológico -TIC- donde priman los aspectos técnicos, muchas veces ininteligiblespara el cliente), con el objetivo de reducir el ratio de fracaso de proyectos.Mejorar la situación actual de muchos proyectos es una labor muy compleja, sinembargo, creo que al menos deberíamos destacar los siguientes aspectos, clavepara reducir el riesgo de fracaso en los proyectos:1. Supervisar no es suficiente. Gestionar un proyecto no es usar un Project, esmucho más.2. Hay que gestionar las restricciones (gestión continua).3. Los objetivos del proyecto tienen que ser claros y estar comunicados.4. Definamos procesos simples y claros. La Metodología no puede ser un fin en simismo.5. Tenemos que estar alineados con negocio. En general, la tecnología no es unfin en sí mismo, es un medio para alcanzar un objetivo mayor.6. Los requisitos del proyecto tienen que ser completos, estar documentados y,sobre todo, acordados con el cliente.
  18. 18. 7. Es importante saber manejar los conflictos (siempre habrá: con el equipo, conotros departamentos, incluso con el cliente)8. Hay que implicar a todos los afectados/interesados (stakeholders) por elproyecto.9. Hay que gestionar constantemente la incertidumbre (gestionar los riesgosevitando improvisaciones).10. Hay que tomar decisiones en base a datos medidos: pero ojo, hay que medirdatos relevantes, no medir por medir.11. Piensa antes de actuar: la planificación no es una pérdida de tiempo. ¿Qué herramientas de planificación usan los Jefes de Proyecto?Recientemente he leído un post que hacía mención a una encuesta sobre el tipode herramientas que suelen usar los Jefes de Proyecto. Podéis acceder a laencuesta a través de este enlace: PM Survey results project schedule. Al igual queindica el autor, la mayoría de los resultados no me han sorprendido y, sin entrar enconsideraciones del ámbito de la encuesta, en lineas generales creo que reflejabastante bien la realidad de la función de gestión de proyectos.
  19. 19. Estas son las conclusiones de la pequeña encuesta:Microsoft Project es la herramienta de planificación más utilizada.  La mayoría de los Jefes de Proyecto no comparten el cronograma con el equipo de proyecto.  La gestión de costes no se hace de forma integrada con la herramienta de planificación, y se realiza mediante otras herramientas (como puede ser Microsoft Excel).  El esfuerzo de los recursos no se gestiona de forma integrada en la propia herramienta de Planificación. Esta pequeña muestra saca a la luz lo que a mi entender son algunas de lasgrandes debilidades (malas prácticas) que actualmente tienen muchos jefes deproyecto:  Muchos proyectos fallan estrepitosamente en la comunicación, y en muchas ocasiones es culpa de una mal entendida política de privacidad y confidencialidad. La labor de dirección de proyectos tiene que ser una labor compartida por todo el equipo de proyecto, aunque la responsabilidad recaiga sobre el director de proyecto, y para ello es necesario que la información fluya dentro del equipo. El cronograma es una pieza fundamental durante la gestión del proyecto, ya que nos permite tener una visión global de lo que hay que hacer y cual es la situación actual. Cada miembro del equipo de proyecto no solo tiene que conocer sus tareas, sino entender como encajan dentro del plan global.  Si ya es difícil de por si es gestionar un proyecto, más difícil será si tenemos toda la información desagregada en distintas herramientas que hacen que el trabajo de actualización de información sea un trabajo laborioso. El problema es que muchas veces el Project simplemente es usado como una herramienta para "pintar" el calendario (como si fuera un Excel de registro
  20. 20. de tareas y fechas), cuando realmente es un potente gestor (exagerando un poco podríamos decir que es un pequeño ERP) con el que podemos gestionar de forma integrada, el tiempo, el esfuerzo y los costes de nuestro proyecto, pudiendo realizar un seguimiento cuantitativo utilizando modelos con el EVA (Earned Value Analysis - Análisis del Valor Ganado). Las causas de este problema seguramente son muy variadas, pero la formación, o más concretamente, el desconocimiento de la funcionalidad del project, nos lleva a esta situación.A la vista de estos datos, y de lo que podemos constatar a nuestro alrededor, sehace cada vez más importante potenciar la función de gestión de proyecto, yremarcar que es algo más que realizar una gestión técnica de las tareas de unproyecto. Tanto las organizaciones como los propios interesados tienen quepreocuparse de cubrir estos gaps en la función de dirección de proyectos, yaprender a utilizar todo el potencial que las herramientas nos aportan. Pero ojo, nonos centremos solo en las herramientas, esto solo sería el segundo paso. Elprimer paso sería tener la base teórica necesaria sobre la función de dirección deproyectos que nos aportan guías como el PMBOK (Project Management Body ofKnowledge). La importancia de la gestión de costes como elemento integrador en las compañíasNo sé si tenéis la misma sensación que yo, pero la ausencia del enfoque en lagestión de costes es muy acusada en la mayoría de los proyectos, al menos en elámbito TIC. Cuando hablas con alguien de un proyecto, siempre destaca lasbondades técnicas, la nueva tecnología o arquitectura que van a usar, lafuncionalidad que va a cubrir, pero nunca se habla de los costes o aspectosfinancieros (lo rentable que va a ser para la organización, etc.,...). Muchas vecesparece que la gestión económica es considerada, por muchos jefes de proyecto,como ese mal necesario para hacer lo que realmente les gusta (normalmente
  21. 21. experimentar con nuevas tecnologías, herramientas o arquitecturas). Muchoshemos tenido esa "deformación" profesional (y me incluyo).En este breve post, me gustaría resaltar la importancia de la gestión económica encualquier actividad, y no lo voy a hacer con la clásica perspectiva de los beneficios(una empresa tiene que ganar dinero y, si se dedica a hacer proyectos, losproyectos tienen que ser rentables). La perspectiva que le quiero dar es que lagestión de costes es como un factor integrador dentro de la compañía. Me explico.Muchas veces en las organizaciones cada uno de nosotros vivimos en el micromundo (departamento) en el que trabajamos y hablamos con nuestroscompañeros de temas comunes, que todos entendemos porque somos del "mismoentorno". El problema viene cuando tenemos que interactuar con otrosdepartamentos: os suena las expresiones, "ya están aquí los raros de losinformáticos, no hay quien entienda lo que dicen" o "el usuario no sabe lo quequiere y solo se fija en las pantallitas", etc. etc. etc. El problema es que en rarasocasiones nos ponemos en la piel del de enfrente e intentamos hablar su mismoidioma. ¿Os imagináis una reunión con un abogado, un economista, un informáticoy un psicólogo hablando en su propio "idioma" y "jerga"? Saldríamos todos con unbuen dolor de cabeza, después de muchas discusiones y malos entendidos.Al final es necesario encontrar un lenguaje que todo el mundo entienda, y que nospermita explicar los proyectos, sus ventajas e inconvenientes, desde un punto devista que desde el abogado al economista de la empresa puedan entender, y ellenguaje económico nos puede ayudar. Por eso, en todos los cursos y seminariosen los que participio remarco lo importante que es en la actualidad que los equiposde proyectos, sus miembros, sepan entender el lenguaje económico, gestionencostes, y sean capaces de vender las bondades de un proyecto desde todos lospuntos de vista: funcional, técnico y, también, económico. En cuantas reunionesde presentaciones de proyecto habéis estado en las que salís con la sensación deque nadie os ha entendido, o lo que es peor, con vuestra idea de proyectorechazada. Es necesario vender las bondades de un proyecto desde todas las
  22. 22. perspectivas, incluso la económica, y que los interlocutores nos comprendan. Porello tenemos que familiarizarnos con términos como: VAN (NPV - Net PresentValue), TIR (IRR - Internal Rate of Return) , Rentabilidad, Retorno de Inversión(ROI - Return on Investment), etc... y tienen que empezar a formar parte denuestros indicadores de gestión en los proyectos como un "must be", uno más delos distintos indicadores de gestión de un proyecto. Por qué fracasan los proyectos  Corrupción del Alcance  Ignorar los Riesgos del Proyecto  Falta de Implicación de los participantes (usuario, equipo proyecto,...)  Requisitos Ambiguos  No se gestionan las expectativas  Objetivos poco claros  Ausencia de Planificación formal  Roles no definidos y/o comunicados  Estimaciones errores/poco realistas  Ausencia de metodologías, plantillas y documentación  Falta de recursos  Falta de Formación  Poco o nulo soporte de dirección
  23. 23. Principales causas del fracaso de los proyectosNo es fácil enumerar las razones por las que fracasan los proyectos y el motivo esque son muy diversas. Sin embargo, y después de participar en múltiplesproyectos, yo destacaría las siguientes:  Falta de implicación/compromiso de los participantes. Equipos desmotivados por objetivos inasumibles, usuarios del cliente que no creen en el proyecto y, o no participan o, lo que es aún peor, entorpecen el normal desarrollo del proyecto, etc... Para que un proyecto salga adelante es muy importante la participación activa de todos sus implicados.  Pobre comunicación. Muchos problemas vienen determinados por una falta de entendimiento incluso, y a veces esto es una crítica a los "técnicos", no somos capaces de ponernos en la piel del usuario y nos encerramos en jergas excesivamente técnicas que confunden más que ayudan. Otros problemas vienen derivados de la falta de fluidez de la información. Muchas personas llevan a rajatabla la teoría de "la información es poder" y se convierten en auténticos cuellos de botella en la comunicación del proyecto.
  24. 24.  La falta de definición de roles y responsabilidades. Es imprescindible que al principio del proyecto quede claramente identificado quien es responsable de cada parte, tanto por parte del cliente como por parte del equipo de proyecto. El objetivo es evitar el uso de la técnica "balones fuera".  Gestión de las expectativas. Más allá de una simple definición de requisitos, a veces falla realmente entender que es lo que espera el usuario/cliente de este proyecto. Lo difícil es identificar las necesidades no declaradas formalmente.Estas y otras situaciones ponen en peligro el normal desarrollo de los proyectos loque incrementa el riesgo de fracaso. Pero al final todas estas causas las podemosresumir en una: POBRE GESTIÓN. Metodologías como el PMBOK (ProjectManagement Body of Knowledge) definido por el PMI (Project ManagementInstitute) identifican los procesos y las herramientas que ayudarán a reducir elriesgo de fracaso de un proyecto Cuando hablamos de CALIDAD ¿entendemos todos lo mismo?¿Cómo definirías la calidad? Cuando se habla de calidad lo primero que se nosviene a la cabeza son defectos/errores, y una serie de procesos y metodologíasque tienen dicho enfoque como Six Sigma (defecto 0), Lean, Metodologías dePruebas/Testing,…Pero... ¿realmente la calidad son solo defectos? Si nos atenemos a como defineel IEEE la Calidad de Software, esta tiene que ser medible y predecible (es decir,no reactiva) y se basa en tres pilares:1. Ausencia de defectos2. Satisfacción del usuario3. Conformidad con los requisitosDicho de otro modo, hablar de calidad es algo más que hablar de errores. Elsegundo punto es especialmente importante ya que tiene que ver con
  25. 25. percepciones del usuario: la aplicación, el producto entregable, puede funcionarcorrectamente pero no satisfacer al usuario, incluso aunque concuerde con lo queestaba redactado en los documentos de especificación (me viene a la cabeza unejemplo clarísimo: seleccionamos la pintura con el pintor, no dudamos, perocuando tenemos toda la habitación pintada.... no nos gusta).Entonces, ¿Qué es la calidad? Calidad es satisfacer las expectativas de nuestrosclientes o, de una forma más amplia, satisfacer las expectativas de losinteresados/participantes (stakeholders) en el proyecto.Con estas consideraciones, podríamos definir la calidad como:  La capacidad o aptitud de un producto o servicio para satisfacer las necesidades y expectativas del cliente, declaradas o implícitas.Y aquí ha salido otro aspecto especialmente relevante. Las expectativas delcliente no siempre son explicitas, están ocultas y es labor del jefe de proyecto ydel especialista funcional hacerlas aflorar, aspecto realmente complicado peroclave para conseguir enfocar bien el proyecto. ¿Qué es la Administración de Proyectos?La administración de proyectos es la aplicación de conocimiento, habilidades,herramientas, y técnicas a actividades de proyectos de manera que cumplan oexcedan las necesidades y expectativas de partidos interesados de un proyecto.Cumplir o exceder las necesidades o expectativas de los partidos interesadosinvariablemente involucran balancear demandas que compiten entre sí, talescomo:•Alcance, tiempo, costo y calidad.•Partidos interesados con diferentes necesidades y expectativas.•Requerimientos identificados (necesidades) y requerimientos no identificados(expectativas).
  26. 26. El término administración de proyectos es a veces usado para describir unaaproximación organizacional a la administración de operaciones sucesivas. Estaaproximación, más propiamente llamada administración por proyectos, tratamuchos aspectos de operaciones sucesivas como proyectos para poder aplicar laadministración de proyectos a ellas. Aunque un entendimiento de la administraciónde proyectos es obviamente crítica para una organización que está administrandopor proyectos, una discusión detallada de esta aproximación esta fuera delalcance de este documento.El conocimiento acerca de la administración de proyectos puede ser organizadode muchas maneras. Este documento tiene dos secciones principales y docecapítulos como se describe a continuación. El Marco de la Administración de ProyectosParte I, el Marco de la Administración de Proyectos, provee la estructura básicapara entender la administración de proyectos.Capítulo 1, Introducción, define los elementos claves y provee una vista del restodel documento.Capítulo 2, El Contexto de la Administración de Proyectos, describe el ambienteen el cual los proyectos operan. El equipo de administración de proyectos debecomprender este contexto más amplio — administrar las actividades día a día deun proyecto es necesario para su éxito pero no es suficiente.Capítulo 3, Los Procesos de Administración de Proyectos, describe una vistageneralizada de como los procesos varios de la administración de proyectosinteractúan comúnmente. Entender estas interacciones es fundamental paraentender el material que se presenta del Capítulo 4 al 12.
  27. 27. Las Áreas de Conocimiento de la Administración de ProyectoParte II, las Áreas de Conocimiento de la Administración de Proyecto, describenconocimiento y prácticas de la administración de proyectos en término de suscomponentes de proceso. Estos procesos han sido organizados en nueve áreasde conocimiento.Capítulo 4, Administración de la Integración de Proyectos, describe los procesosrequeridos para asegurar que los elementos varios de un proyecto estáncoordinados apropiadamente. Consiste del desarrollo de un plan de proyecto,ejecución del plan de proyecto, y el control de cambios en general.Capítulo 5, Administración del Alcance del Proyecto, describe el proceso requeridopara asegurar que el proyecto incluye todo trabajo requerido, y sólo el trabajorequerido, para completar el proyecto de manera exitosa. Consiste de la iniciación,planeación del alcance, definición del alcance, verificación del alcance, y controlde cambio al alcance.Capítulo 6, Administración del Tiempo del Proyecto, describe los procesosrequeridos para asegurar la terminación a tiempo del proyecto. Consiste en ladefinición de las actividades, secuencia de las actividades, estimación de duraciónde las actividades, desarrollo del cronograma y control de la programación.Capítulo 7, Administración de los Costos del Proyecto, describe los procesosrequeridos para asegurar que el proyecto es completado dentro del presupuestoaprobado. Consiste en la planificación de recursos, estimación de costos,presupuestario de costos, y control de costos.Capítulo 8, Administración de la Calidad del Proyecto, describe los procesosrequeridos para asegurar que el proyecto satisfacer las necesidades para lo cual
  28. 28. fue desarrollado. Consiste en la planeación de la calidad, a seguranza de lacalidad, y control de calidad.Capítulo 9, Administración de los Recursos Humanos del Proyecto, describe losprocesos requeridos para hacer el uso más eficiente de las personas involucradasen el proyecto. Consiste en la planeación organizacional, adquisición de staff, ydesarrollo del equipo.Capítulo 10, Administración de las Comunicaciones del Proyecto, describe losprocesos requeridos para asegurar la generación apropiada y a tiempo, colección,diseminación, almacenamiento, y la disposición final de la información delproyecto. Consiste en la planeación de la comunicación, distribución de lainformación, reportes de desempeño, y el cierre administrativo.Capítulo 11, Administración de Riesgo del Proyecto, describe los procesosconcernientes con la identificación, análisis, y respuesta a el riesgo del proyecto.Consiste en la identificación del riesgo, cuantificación del riesgo, desarrollo de larespuesta al riesgo, y en el control de la respuesta al riesgo.Capítulo 12, Administración de la Procuración del Proyecto, describe los procesosrequeridos para adquirir bienes y servicios de fuera de la organización ejecutora.Consiste en la planeación de la gestión de la procuración, planear la solicitación, lasolicitación, selección de proveedores, administración de contratos, y cierre decontratos.El Contexto de la Administración de ProyectosLos proyectos y la administración de proyectos operan en un ambiente más amplioque el del proyecto mismo. El equipo de administración de proyectos debeentender este contexto más amplio - administrar día a día la actividades delproyecto es necesario para el éxito de este, pero no suficiente. Este capítulo
  29. 29. describe aspectos claves del contexto de la administración de proyectos, que noestán descritos en otras partes de este documento. Los tópicos incluidos aquí son:2.1 Fases del Proyecto y el Ciclo de Vida del Proyecto2.2 Los Partidos Interesados del Proyecto2.3 Influencias Organizacionales.2.4 Habilidades Claves de Administración General2.5 Influencia SocioeconómicasFases del Proyecto y Ciclo de Vida del ProyectoPorque los proyectos son tareas únicas, involucraran cierto nivel de incertidumbre.Las organizaciones ejecutaras de proyectos generalmente dividirán cada proyectoen fases del proyecto para poder administrar mejor los enlaces apropiados con lasoperaciones de la organización ejecutara. De manera colectiva, estas fases seconocen como el ciclo de vida del proyecto.Características de las Fases del ProyectoCada fase del proyecto es marcada por la terminación de una o más entregas.Una entrega es un tangible, un producto de trabajo verificable tal como un estudiode factibilidad, un detalle de diseño, o un prototipo que trabaje. Las entregas, y portanto las fases, son parte generalmente de una secuencia lógica diseñada paraasegurar una definición apropiada del producto del proyecto.La conclusión de una fase de proyecto es generalmente marcada por la revisiónde tanto las entregas como del desempeño del proyecto para poder (a) determinar
  30. 30. si el proyecto debe continuar a su próxima fase y (b) detectar y corregir errores demanera eficiente. Estas revisiones de final de fase generalmente se llaman salidasde fase, puertas de fase o puntos muertos.Cada fase de proyecto normalmente incluye una serie definida de productos detrabajo diseñados para establecer el nivel deseado de control administrativo. Lamayoría de estos ítems están relacionados con la entrega de la fase primaria, y lasfases típicamente toman sus nombres de estos ítems: requerimientos, diseño,construcción, texto, comienzo, entrega, y otros como sea apropiado.Características del Ciclo de Vida del ProyectoEl ciclo de vida del proyecto sirve para definir el comienzo y el final de un proyecto.Por ejemplo, cuando una organización identifica una oportunidad a la que legustaría responder, autorizará un estudio de factibilidad para determinar si debeadoptar el proyecto. La definición del ciclo de vida del proyecto determinará si elestudio de factibilidad es tratado como la primer fase de vida del proyecto o comoun proyecto independiente.La definición de ciclo de vida del proyecto determinará también que acciones detransición se incluirán al final del proyecto y cuáles no. De esta manera, ladeterminación del ciclo de vida del proyecto puede ser usado para enlazar elproyecto a operaciones sucesivas de la organización ejecutora.La secuencia de fase definida por la mayoría de los ciclos de vida del proyectogeneralmente involucra algún tipo de transferencia en tecnología o intercambiostales como los requerimientos para diseñar, construcción para operaciones odiseño para manufactura. Entregas de la fase precedente son usualmenteaprobadas antes que comience el trabajo en la fase siguiente. Sin embargo, unafase subsiguiente es a veces comenzada antes de la aprobación de las entregas
  31. 31. de la fase anterior cuando los riesgos involucrados se tornan aceptables. Estatáctica de traslapo de fases muchas veces es llamada "Fast Tracking".Los ciclos de vida del proyecto generalmente definen:•Qué trabajo técnico debe ser hecho en cada fase (ej. ¿Es el trabajo del arquitectoparte de la fase de definición o de la fase de ejecución?).•Quién debe estar involucrado en cada fase (e.g. ingeniería concurrente requiereque los implementores estén involucrados con los requerimientos y los diseños).Las descripciones de los ciclos de vida del proyecto pueden ser o muy generales omuy detallados. Las descripciones altamente detalladas tienen muchas formas,tablas y lista de chequeo para proveer estructura y consistencia. Talesaproximaciones de detalle son llamadas a veces metodologías de administraciónde proyectos.La mayoría de las descripciones de ciclo de vida del proyecto comparten unnúmero de características comunes:•Los niveles de empleados y costos son bajos al comienzo, más altos hacia elfinal, y caen rápidamente a medida que se llega a la finalización. Este patrón seilustra en la Figura 2-1.•La probabilidad de completar exitosamente el proyecto es más bajo, y por lo tantoel riesgo e incertidumbre son altos, al comienzo del proyecto. La probabilidad decompletar exitosamente generalmente se vuelve progresivamente más grande amedida que el proyecto continúa.•La habilidad de los partidos interesados para influenciar las características finalesdel producto del proyecto y su costo final son más altas al comienzo y se vuelvenprogresivamente más bajas a medida que el proyecto continúa. La contribuciónmás grande de este fenómeno es que los costos de cambio y de corrección deerrores generalmente se incrementan a medida que el proyecto continúa.
  32. 32. Se debe tener cuidado para distinguir entre el ciclo de vida del proyecto y el ciclode vida del producto. Por ejemplo, un proyecto desarrollado para introducir unanueva computadora al mercado es solo fase del ciclo de vida de un producto.A pesar de que muchos ciclos de vida del proyecto tienen nombres de fasessimilares con trabajo similar requerido para los productos, muy pocos sonidénticos. La mayoría tienen cuatro o cinco fases pero algunos tienen nueve omás. Aún dentro de una sola área de aplicación pueden haber variacionessignificativas - un ciclo de vida de desarrollo de software de una organizaciónpuede tener una sola fase de diseño mientras que la de otra organización puedetener fases distintas para el diseño funcional y de detalle.Los subproyectos dentro de proyectos pueden también tener ciclos de vida deproyectos distintos. Por ejemplo, una firma de arquitectura contratada para diseñarun nuevo edificio de oficinas está primero involucrada con la fase de definición deldueño cuando está elaborando el diseño y en la fase de implementación del dueñomientras que da soporte al esfuerzo de construcción. El proyecto de diseño delarquitecto, sin embargo, tendrá sus propias series de fases que van desde eldesarrollo conceptual pasando por la definición, implementación y cierre. Elarquitecto puede inclusive tratar el diseño y el soporte a la construcción comoproyectos separados con sus propias fases distintas.http://www.liderarproyectos.com/

×