¿Como lograr el exito personal?.. Manejando bien las tecnicas de la gerencia

Areas de la gerencia de proyecto

En este post hablare de dos áreas de la gerencia de proyectos que pueden ayudar a alcanzar nuestras metas y a hacernos más exitoso: la gerencia de alcance y de tiempo. En este post repasaremos a tres otras áreas de la gerencia de proyectos que puedan también ser utilizadas en tu búsqueda del éxito: la gerencia de coste, de calidad y de riesgos.

Gerencia de Coste

Cualquier búsqueda de mérito en la vida te costará algo. Puede costarte el dinero, o puede costar simplemente tiempo y esfuerzo. Necesitas entender los costes y las ventajas y comparar uno contra el otro para decidir si la búsqueda tiene mérito.

Un concepto importante en la gerencia del coste es lo qué se llama los costes hundidos. Los costes hundidos son los costes que fueron incurridos en el pasado, y no deben ser considerados más al decidir sobre una línea de conducta futura. Por ejemplo, si has gastado ya cierta cantidad de dinero buscando un grado en un área que has decido no es derecha para ti, no lo acabas apenas porque has gastado ya dinero en él. Es decir, no lance el buen dinero después del mal dinero.

Una vez que hayas decidido que tu proyecto es una búsqueda de mérito, necesitas crear un presupuesto para tu proyecto. Sí, los presupuestos no son muchos divertidos. Pero son un componente importante del éxito financiero.

Gerencia de la Calidad

La calidad es un componente importante de la gerencia de proyectos. Uno de los conceptos dominantes de la gerencia de la calidad que debes entender es que es más rentable hacer las cosas derechas la primera vez que tener que volver a hacerlas más adelante. Cuando estás trabajando en una tarea, tomes el tiempo y el esfuerzo necesarios para hacerla derecha la primera vez. Esto no significa que no puedes mejorar.

Una de las técnicas en la gerencia de la calidad que puedes utilizar a tu ventaja es la reducción de la variabilidad. Cuanto más constante eres en tu proyecto, más alta es la probabilidad que tú tendrás un producto de la alta calidad.

La calidad no significa necesariamente gastar más, o hacer algo de más lujo de qué has planeado originalmente. De hecho, de una perspectiva de la gerencia de proyectos, un proyecto de calidad entrega un resultado final que resuelva los requisitos y la aptitud del uso, nada más, nada menos.

Gerencia de Riesgos

Finalmente, el manejo de los riesgos es dominante al éxito de tu proyecto y a tu éxito personal. Entiendas los riesgos de tu proyecto enumerando las cosas que pueden ir mal, el impacto de esos riesgos, y la probabilidad que ocurrirán. Concéntrese en los riesgos que tienen la probabilidad más alta y el impacto más grande. Pienses delante de tiempo de cómo reaccionarías si se accionan estos riesgos. La parte más importante de la gerencia de riesgos es el pensamiento que pones en preparación para cuando ocurren esos riesgos.

Esto concluye esta serie de cómo las técnicas de gerencia de proyectos pueden ayudarte a alcanzar tus metas y a ayudarte a ser una persona más exitosa.

La gestión estrategica de proyectos

La gestión estrategica de proyectos como servicio de alto valor para los clientes

En este post voy a tratar de porque es importante alinear la gestión de proyectos con la estrategia de negocio.

Cuando hablamos de prestar servicios muchas veces pensamos que simplemente nos están contratando personas que hagan una gestión técnica, con un conocimiento particular que cumpla con determinadas tareas para asegurar un entregable especifico; pero simplemente eso no es suficiente.

La gestión de proyectos debe estar alineada en su totalidad con la estrategia de negocio, ofreciendo al cliente alternativas concretas, seguimiento e información oportuna de la gestión de cada uno de los involucrados en decisiones. Es fundamental que se cumpla con los objetivos de costos de los proyectos, si hoy haces ganar a tu cliente en el futuro seguirás ganando en conjunto con el. Igualmente la gestión estratégica de los proyectos, debe basarse en un servicio que facilite a la compañía la obtención de ventajas competitivas con propuestas de valor que la beneficien.

Una gerencia enfocada en el servicio determina al que hace el proyecto como un aliado estratégico vital para el negocio, por la relevancia que este puede llegar a presentar en la gestión. no piense en cobrar , lleve su gestión mas allá de su rol técnico; hágale sentir a su cliente que usted esta trabajando para su negocio enfocado en los clientes de este, anticipe los problemas, comuníquenlos inmediatamente y construya los planes de acción en conjunto con su cliente. Se requiere fidelizar a sus clientes a través de estándares de calidad superiores, de tal manera que su cliente sienta que Usted es parte vital en su gestión; determine claramente los riesgos que tiene la compañía en sus proyectos y el impacto que los mismos pueden tener en el negocio de su cliente, no piense exclusivamente en los riesgos para su labor como Gerente de proyecto.

En conclución la clave esta en conocer muy bien a su cliente y que obtendrá el negocio con su trabajo, siempre lleve su gestión mas allá de sus conocimientos técnicos, enfóquese en la calidad que su cliente necesita, en elementos que generen beneficios competitivos para su cliente, una alta productividad de su gestión y asegure que las estrategias de su cliente sean apoyadas por su Servicio.

Capacitación en Gerencia de Proyectos

¿Capacitar a las organizaciones en gerencia de proyectos?

En actualidad vemos que las empresas tienen claro que el recurso más importante con el que cuentan es la gente que las conforma. Por todos lados se oye hablar de la importancia que tiene para el desempeño organizacional, el conocimiento acumulado, tanto en los integrantes de una organización, como en la organización misma.

El Knowledge Management, como se le ha dado a llamar , consiste en transferir el conocimiento y experiencia existente entre sus miembros, de tal forma que pueda ser utilizado como un recurso disponible para otros en la organizaciòn.

Sin embargo, en pocas ocasiones las organizaciones reconocen que es cada vez más demandante la tarea de administrar eficientemente sus proyectos, por lo que importante trabajar desde ese nivel, la parte humana de la compañía, para dar mejores resultados tanto en la parte técnica como operativa del negocio.

También se ve que muchas empresas , se están dedicando a adoptar prácticas estandarizadas y estructuradas de administración de proyectos. El mismo Project Management Institute (PMI©) ha reportado que cada vez más empresas utilizan metodologías y herramientas que permiten una administración profesional de sus proyectos.

Para que las organización puedan adoptar una cultura de administración de proyectos, tendrá que efectuar cambios en sus políticas y procesos para instrumentar el cambio “técnicamente”. Sin embargo, éste es un cambio cultural que necesita ser asimilado y entendido por las personas que trabajan directamente con la ejecución de los proyectos, por tanto los procesos y/o metodologías de administración de proyectos requieren de un convencimiento y ejemplificación clara de que realmente agregan valor al trabajo diario de las personas. En este punto es donde se tiene que empezar con este cambio de cultura, con una estrategia de capacitación e involucramiento en todos los niveles organizacionales de una empresa.

Si la organización no tiene bien definida una estrategia de capacitación en administración de proyectos, ésta estará más propensa a cometer errores estratégicos en la implementación del proceso de capacitación. Algunos ejemplos son:

• Dejar absoluta libertad a los involucrados en el proceso para escoger en el mercado la capacitación que tomarán:Cuando esto sucede, la calidad de la capacitación recibida puede ser heterogénea. Entonces el problema principal no será este, sino que la capacitación recibida no estará suficientemente estandarizada. Al darse esta situación de que los involucrados salgan al mercado a buscar capacitación,sin una idea clara de lo que se requiere, se tendrá capacitación cuyos resultados serán definitivamente mediocres.

• La misma capacitación para todos los niveles:Muchas veces se decide capacitar de la misma forma a todos los involucrados en la realización de proyectos por lo que directivos, patrocinadores, líderes de proyecto y miembros de los equipos de trabajo tendrán el mismo enfoque, el cual no corresponde necesariamente con los roles específicos que estas personas desempeñarán en la realización de los proyectos.
  
• Las personas y la organización no Aprehenden:Esta palabra no esta mal escrita. Hay una diferencia básica entre aprender y aprehender. El significado de esta palabra implica mas que adquirir conocimientos. Implica que, la persona capacitada, una vez que adquirió nuevos conocimientos, regresa a su trabajo o a su vida diaria y modifica su actuación en base al conocimiento adquirido.

Una estrategia integral:

Se dice que capacitación no es suficiente nunca. El esfuerzo de aprendizaje de la organización, tiene que estar acompañado por las estrategias descritas a continuación. Como mínimo dos de ellas:

1.Una Metodología corporativa de Administración de proyectos. Estandarizada, ágil que todos los miembros de la organización utilizan de forma obligatoria al administrar sus proyectos.

2.Compromiso total de la alta dirección.

3.Una estrategia formal de Cambio cultural, que se enfoque a difundir los beneficios organizacionales y personales

4.Una Oficina de Proyectos (PMO): que coordine todos los esfuerzos.

Como conclusión podemos decir que el factor más importante en la adopción de la Administración de Proyectos, es la capacitación, ya que no se puede ni debe verse como un elemento aislado.La capacitación que se va a realizar , debe tener un balance entre Segmentación por involucrados en la Administración de Proyectos y Estandarización de las herramientas, lenguaje y conocimientos transmitidos. Por lo tanto debe ser un esfuerzo planeado, diseñado y medido.

¿Cómo PRINCE2 puede servir de complemento a PMBOK?

Acerca de PRINCE2

En este post veremos una visión general de PRINCE2 , donde se examinaran las similitudes y diferencias entre el PMBOK y PRINCE2. Ver como estos dos enfoques de la gestión del proyecto se complementan mutuamente, y cómo el PRINCE2 metodología de gestión de proyectos aporta un valor añadido a un PMBOK base de conocimientos.

¿Que es PRINCE2? Abreviatura de "Proyectos en entornos controlados", fue desarrollado en 1989 por la administración pública del Reino Unido como estándar para la gestión de proyectos de informática. Desde entonces el método ha sido mejorado y adaptado de una manera que hoy es apto para todo tipo de proyecto. PRINCE2 es utilizado en muchas áreas del sector público y privado y es reconocido como el estándar de gestión de proyectos en el Reino Unido y en muchos otros países.

PRINCE2 es un método general, ajustable de gestión de proyectos. Abarca la organización, la dirección y el control de proyectos. Los principios de PRINCE2 son aplicables para todos tipos de proyectos.PRINCE2 ayuda a controlar riesgos, asegurar la calidad y organizar procesos de cambio eficazmente.

PRINCE2 es un proceso basado en la gestión de proyectos estructurada la metodología que pone de relieve cómo ocho componentes particulares, cuando se entiende y aborden de manera efectiva, puede reducir los riesgos en todos los tipos de proyectos. Aunque PRINCE2 se basa en el mismo terreno como el PMBOK , proyectores, un número de áreas para concretar PMBOK, y responde a la pregunta "¿cómo aplicar estos conceptos en mis proyectos?" .

La estructura de PRINCE2

PRINCE2 no pretende ser tan amplio como el PMBOK . PRINCE2 se basa en los principios del PMBOK . PRINCE2 se centra en los elementos (los "componentes") que se identifica como crucial para el éxito de la evaluación y la realización de un proyecto. Se construye un proceso para vincular esos elementos juntos para reducir el riesgo global del proyecto, y proporciona técnicas de apoyo a ellos. "La Guía para el PMBOK " específicamente pide a la práctica de aplicar una metodología de gestión de proyectos (como una herramienta / técnica), y PRINCE2 proporciona una.

PRINCE2 sus componentes y procesos sean compatibles con el PMBOK, pero no incluye todas las áreas de conocimiento y datos que se especifican en el PMBOK . PRINCE2 se centra en áreas críticas, por lo que un director de proyecto todavía puede necesitar recurrir a la profundidad y el alcance del PMBOK y otras fuentes para completar algunas áreas de la gestión de proyectos de trabajo. La intención de PRINCE2 es organizar y orientar la gestión de los proyectos los conocimientos de una manera adecuada para la mayoría de los entornos proyecto. Se supone que el aprendizaje y los que trabajan con esta metodología tienen un nivel de experiencia que les permite rellenar los detalles que omite PRINCE2. PRINCE2 en la escala y en el contenido de sus procesos, componentes y técnicas deben adaptarse al tamaño y la naturaleza del proyecto.

PRINCE2 Componentes

Estos componentes no son tan ampliamente como se definen las áreas de conocimiento.Los procesos de PRINCE2 interactúan con 8 componentes básicos:

• Business Case: Documentación corresponde a la fase previa al inicio del proyecto, la cual definirá el rumbo del proyecto.


• Organización: El proyecto requerirá recursos de la organización, deberán tomarse decisiones de inversión y efectuar un control presupuestario.


• Planes: Espina dorsal del proyecto, donde se detalla la planificación de las diferentes partes del mismo.


• Controles: Es necesario es garantizar el cumplimiento de los requisitos, el control de las desviaciones en tiempo/costes y la verificación de que la viabilidad del proyecto no se ve afectada según los criterios establecidos en el Business Case.


• Gestión del riesgo: Análisis del riesgo y definición de estrategias para afrontarlo.


• Gestión de la calidad: Los requerimientos de calidad son descritos mediante “Product Descriptions”, preparados por el Project Manager y aprobados por el Project Board.


• Gestión de configuraciones: Proporciona mecanismos para realizar seguimiento y control de los entregables y los aspectos pendientes (issues).


• Gestión del cambio: Verifica el impacto de cambios potenciales sobre el Business Case, siendo un apoyo fundamental para la toma de decisiones.

PRINCE2 Procesos

Los proyectos gestionados mediante PRINCE2 se descomponen en etapas (stages) y se encuentran gestionados por los siguientes procesos:

• Puesta en marcha del Proyecto :Diseño y elección del equipo de trabajo (incluido el Project Board), definición de la necesidad a cubrir y el approach para afrontarla.


• Dirección del Proyecto : Tiene lugar durante todo el proyecto y permite al Project Manager consultar y solicitar apoyo/autorización al Project Board.


• Iniciación del Proyecto : Análisis y definición de los requerimientos y elementos críticos mediante la creación del documento PID (Project Initiation Document).


• Gestión de los limites de las etapas :Gestión de la transición de una etapa a la siguiente, proporcionando información al Project Board para validar la aceptación del paso de etapa.


• Control sobre una etapa :Trabajo diario del Project Manager, el cual se encarga de la gestión de cambios, recolección de información sobre el grado de avance, toma de decisiones para la aplicación de medidas correctivas y, en caso de ser necesario, escalado de problemas o peticiones al Project Board.


• Gestión de la entrega del producto:Sistema de autorización de trabajo, el cual ofrece mecanismos para establecer que trabajo debe ser realizado mediante Work Packages.


• Cierre del proyecto: Se valida que las necesidades han sido cubiertas, se realizan sugerencias de cara a futuro y se liberan los recursos ocupados.


• Planificación : La planificación tiene lugar de forma repetida en diversos procesos.El objetivo es la creación de planes y calendarios en base a los requerimientos, actividades y recursos disponibles.

Aportaciones principales de PRINCE2 sobre PMBOK

Project Board
PRINCE2 introduce la idea de disponer de una junta o Project Board, cuyo principal objetivo radica en facilitar la correcta ejecución del proyecto. En repetidas ocasiones, sobretodo en organizaciones que no trabajan orientadas a proyectos y estos son puntuales, el Project Manager controla y dirige el proyecto pero no dispone de suficiente autoridad. Sin embargo, si se constituye un Project Board con miembros pertenecientes a la cúpula directiva media o alta, el Project Manager puede superar las limitaciones en su autoridad mediante esta junta.

Product Breakdown Structure, Product Descriptions y Product Flow Diagram
PRINCE2 se orienta a la generación de productos, entendiendo producto como un elemento tangible (p.ej. maquinaria, documentos, etc.) o intangible (p.ej. software).
Con dicha finalidad, PRINCE2 presenta la técnica de la generación del Product Breakdown Structure (PBS). El PBS es utilizado para la identificación tanto de los entregables (productos específicos) como de los productos (p.ej. documentos) necesarios para la gestión (productos de gestión).Una vez se dispone del PBS, se procede a elaborar el Product Flow Diagram donde se definen las dependencias entre productos y el orden de creación.

Una vez definidos el Product Breakdown Structure y el Product Flow Diagram, se procede a la definición de tareas y actividades orientadas a la generación de los diferentes productos.
Esta técnica puede ser considerada como complementaria a la generación del Work Breakdown Structure (WBS) que define PMBOK para la descomposición de las fases y actividades del proyecto.

Work Packages
Los paquetes de trabajo se representan por un conjunto de información que detalla la creación de uno o más productos. El contenido de los mismos se encuentra compuesto por los siguientes elementos:

• Product Descriptions (uno o varios)


• Planificación en tiempo y coste


• Autorización del Project Manager


• Información sobre potenciales riesgos


• Indicaciones sobre:


• Cómo el trabajo será revisado, comprobado y aprobado


• Cómo seran reportados los problemas y sugerencias

Gestión del cambio
La gestión del cambio permite organizar y analizar solicitudes para la incorporación de cambios al proyecto y garantizar las siguientes premisas:
Si un producto debe ser modificado, se deben validar los cambios en el Product Description.
Una vez un producto ha sido aprobado, el Project Manager no puede autorizar ningún cambio sobre el mismo sin la aprobación del Project Board.
Todos los cambios o solicitudes de cambio deben ser registrados en un Issue Log, especificando:

• Descripción


• Evaluación


• Decisiones


• Estado
  

De esta forma se facilita la catalogación, seguimiento y revisión de cuestiones durante el proceso de Control y en la finalización de cada etapa (Managing Stage Boundaries).

Quality Review
En cualquier momento del proyecto se pueden efectuar revisiones de calidad con el objetivo de:

• Validar que los productos cumplen los requisitos (Product Descriptions)


• Proporcionar oportunidades de mejora continua


• Involucrar a todas las partes que tienen un determinado interes en los diferentes productos


• Proporcionar un mecanismo para la monitorización y el control

Las revisiones pueden ser efectuadas por personas independientes al Project Manager y constan de diversos pasos básicos:

• Confirmación de que el producto se encuentra listo para ser revisado.


• Revisión del producto


• Elaboración del listado de dudas a contrastar con el responsable del producto


• Reunión de contraste donde se definiran acciones futuras


• Notificación al Project Manager y seguimiento

PRINCE2 puede resultar de utilidad para cualquier Jefe de proyecto, permitiendo la selección de aquellas ideas o técnicas que parezcan más idóneas para la tipología de trabajo que este desempeñando. No obstante, cabe destacar que PMBOK es conceptualmente más completo que PRINCE2 y que por tanto, este segundo debe ser tratado como un complemento al primero.

Finalmente, señalar que en la web de PRINCE2 se encuentra disponible para su descarga gratuita todo un conjunto de plantillas.

Aquì les dejo un enlace :http://www.elumini.com.br/Images/EntendiendoPrince2_Espanhol.pdf

Como realizar un FMEA

Modos de falla y Análisis de los efectos (FMEA)

Tradicionalmente las empresas que comercializan bienes y servicios, se han visto con el objetivo de satisfacer al cliente, lo cual se ven obligados de ofrecer garantías, esto quiere decir ,de comprometerse con el cliente por un tiempo determinado a reparar o sustituir de manera total o parcial los productos que presenten defectos operacionales o de construcción.

Por eso , es deseable colocar en el mercado un producto o servicio que no presente defectos, y para tal fin en el presente post explicare sobre los modos de fallas y análisis de efectos (FMEA) como un procedimiento de gran utilidad para aumentar la confiabilidad y buscar soluciones a los problemas que puedan presentar los productos y procesos antes de que estos ocurran.

Primero definamos que es un FMEA ,es un proceso para la identificación de las fallas potenciales del diseño de un producto o de un proceso antes de que éstas ocurran, con el propósito de eliminarlas o de minimizar el riesgo asociado a las mismas.

Aunque el método del FMEA generalmente ha sido utilizado por las industrias automotrices, éste es aplicable para la detección y bloqueo de las causas de fallas potenciales en productos y procesos de cualquier clase de empresa, ya sea que estos se encuentren en operación o en fase de proyecto; así como también es aplicable para sistemas administrativos y de servicios.

El proceso para llevar a cabo una Modos de falla y análisis de efectos se resume como sigue:

• Describir producto o proceso
• Definición de Funciones
• Identificar posibles modos de fallo
• Describir los efectos de los fracasos
• Determinar las causas
• Dirección actual de los métodos o los controles
• Calcular riesgos
• Tome Acción
• Evaluar los resultados

Este proceso se puede aplicar a los distintos tipos de FMEAs, que o bien se centran en el sistema, el diseño, proceso, servicio o software de funciones. Cabe señalar que un fallo puede ser introducido después de cualquier cambio y las actualizaciones se hacen con el producto y proceso. Por lo tanto, FMEA puede ser que necesite ser revisado y actualizada cada vez que un nuevo producto o proceso se está introduciendo, los cambios se hacen en las operaciones o un cambio en el proceso de diseño.

FMEA otorga ciertas ventajas para la gestión de proyectos. Se hace hincapié en la prevención del problema y actúa como un catalizador para el trabajo en equipo y el intercambio de ideas saludables. Captura conocimientos de ingeniería y proporciona un foco para la mejora de las pruebas y el desarrollo, a la larga da como resultado una mayor satisfacción del cliente.

Aquí les dejo un enlace para su mejor entendimiento :

http://secretosenred.com/articles/3023/1/MANUAL-DEL-FMEA--AMEF-/Page1.html

ESTADO DE UN PROYECTO INFORMATICO

¿Cómo se debe informar sobre la Situación de un proyecto ?


Son pocas las personas que saben la forma de informar sobre el estado de un proyecto, incluso cuando son expertos gestores de proyectos. Cual es el problema básico? La mayoría de las personas no entienden la perspectiva de un administrador que está siendo presionado para obtener información acerca de un gran proyecto. . Aquí hay algunas reglas básicas de presentación de informes de estado que se deben utilizar para mantener buena gestión ,que el equipo del proyecto este informado y conducir un proyecto de éxito.
Un estado de presentación de informes significa que los directores estén plenamente informados de sus proyectos del avance y dirección general, sin tener que involucrarse ellos mismos.

A partir de los informes de estado le permite a su jefe pasar sólo unos segundos revisando su informe para determinar qué tipo de progresos ha hecho.

Para escribir un excelente estado del proyecto , usted debe entender:

Los tres componentes de la situación.
Cómo escribir breves detalles.
¿Qué datos clave se necesita por parte de la dirección?

Tres componentes de la situación

Hay tres componentes principales a la presentación de informes del estado del proyecto:

Total: Tenemos que ver lasalud global del proyecto .Como gerentes, queremos ser capaces de detectar un proyecto en problemas. Su proyecto podría no ser tan saludable como usted piensa que es.
Hitos: Su proyecto tiene principales logros que deben ser completado por fechas específicas. Los directores quieren ver que los hitos esten completos, cuáles están en marcha, y que son los que viene.

Temas: Su proyecto también tiene probablemente uno o más obstáculos a la conclusión que se han descubierto. Nos gustaría ver breves detalles acerca de cada tema a fin de que podamos tomar una decisión acerca de si o no al paso y ayudar si es necesario.

Breve Detalles :

Su trabajo es informar sobre los detalles de su proyecto en breve. Podría tenertreinta minutos para escribir su estatuto, pero siempre recuerde que su director no tiene treinta minutos para pasar su lectura.Su gerente realista sólo tiene alrededor de 30 segundos para ver el estado del proyecto, ya que pueden tener 30, 40, 100, o incluso exponencialmente más proyectos para los que son responsables.

Existe un enorme valor en un director de proyecto que pueden informar sin condición narrativa. La recomendación es que lo que se escribe sea como si fueron la creación de un anticuado telegrama.

Datos clave :

Gestión de necesidad de ciertos datos que debe presentar con el fin de ver la salud en general, el desempeño contra metas, y la amenaza de las cuestiones presente proyecto.

Una de las cosas más difíciles que un administrador tiene que ver todo el día se decidirá si para darle más espacio o entrar en su trabajo con usted. La prestación de los hitos del proyecto es útil en este sentido,ya que nos permite ver la programación de alto nivel, determinar si el calendario es aceptable tal como está, y predecir los peligros que pueden enfrentar en el camino.

Los Hitos tienen seis componentes:

El nombre hito.
El porcentaje total de la meta.
El comienzo previsto.
El proyecto final.
El inicio efectivo.
El verdadero final.

En conclución podemos decir que para informar el estado de un proyecto, se debe presentar documentos o entregables que no sean muy extensos ,se debe plantear lo mas concreto posible y que sea entendible,asi estaremos gestionando un buen proyecto.

La mezcla de lo tradicional y ágil en la gestión de proyectos

Diferencias entre tradicional y ágil en la gestión de proyectos

Estuve revisando algunos artículos y hubo uno que me intereso mucho, y que me gustaría compartir con ustedes.
Sabemos que las metodologías tradicionales requieren de disciplina, planificación y métodos de control. Las tareas se completa una tras otra en una manera ordenada siguiendo una secuencia, exigiendo una planificación con antelación.

Las metodologías tradicionales suponen que los acontecimientos que puedan afectar los proyectos son predecibles y que las herramientas y actividades son bien entendidas. Además supone que una vez que cuando una fase está concluida, ya no será renovada. Entonces podemos rescatar los puntos fuertes de este enfoque que establecen las medidas para el desarrollo y subraya la importancia de las necesidades.

Sus limitaciones son que rara vez se siguen el flujo secuencial y a los clientes les resulta difícil completar el estado de los requisitos en una fase temprana del proyecto. Este modelo sueles ser visto como una cascada. En la actualidad los procesos de negocio son más complejos e interconectados. Además rechazan las estructuras tradicionales, ya que la organizaciones hacen frente a las presiones de cambio sin precedentes, la competencia mundial, tecnologías en rápida evolución y creciente complejidad en todo momento. Debido a este carácter multifacético de las empresas, los proyectos que ponen en marcha nuevos sistemas de negocio son más complejo.


Metodología ágil en la gestión de proyectos

Esta metodología es iterativa e incremental en los procesos, donde desarrolladores y partes interesadas en el proyecto trabajan activamente juntos para entender el dominio, lo que es necesario identificar las funcionalidades y darles prioridades. El método agiles se utilizan cuando estas condiciones están presentes: el valor del proyecto es claro, el cliente participa activamente en todo el proyecto, el cliente, los diseñadores y desarrolladores interactúan constantemente.

El enfoque Ágil consta de muchas planificaciones rápidas interactivas y desarrollo de ciclos, lo que permite al equipo de proyecto evaluar constantemente la evolución del producto y obtener de inmediato comentarios de los usuarios o interesados. El equipo aprende y mejora el producto, así como sus métodos de trabajo, de cada ciclo. Después de una racionalización de la planificación, la definición de los requisitos y la solución fase de diseño se ha completado se pone en marcha el proyecto, se realizan repeticiones de una planificación más detallada, las necesidades, diseñar, construir y poner a prueba el sistema. Este enfoque nos permite hacer una inmediata modificación de los requisitos del producto. Esta metodología exige una dedicación plena del equipo de proyecto que incluye un cliente o usuario final, donde los miembros del equipo trabajan en la misma localidad.

Para el desarrollo del trabajo se realizan a través de una serie de sesiones donde el equipo escribe el código, a continuación, pruebas de trabajo de los módulos del sistema y repite el proceso. No hay documentación mínima que el equipo se base, casi exclusivamente en informales comunicaciones internas.

Una vez más, podemos decir que este difiere del enfoque tradicional donde uno invierte una considerable cantidad de tiempo en la planificación y una cantidad significativa de los requisitos de documentación.

¿Entonces cual es la adecuada?

La gestión de proyectos, tradicional o ágil, tiene principios muy similares. Se trata de hacer un buen trabajo para el cliente. Se trata de un líder de equipo. Se trata de entregar resultados de negocio medibles. Muchos de estos principios o prácticas pueden aplicarse en la mayoría de equipo de entornos estructurados.
Sin embargo, algunos profesionales de la gestión de los proyectos pueden rechazar los principios de gestión ágil, si no son capaces de adoptar todos los componentes y las prácticas. Esto es un error. Por ejemplo, ¿qué ocurre si no pueden llegar al usuario a sentarse a tiempo completo con el equipo en el taller? Esto no significa que no pueden incorporar algunas de las otras piezas de gestión ágil, tales como el control visual y de la característica basada en el desarrollo. Además, incluso si un usuario no puede participar en una jornada completa, la mayoría de los usuarios están dispuestos a participar en el equipo, especialmente durante los ensayos y la función de prioridades. El resto del tiempo, el analista de negocios puede representar el usuario, mientras que el completo equipo básico sigue trabajando juntos.

Entonces podemos decir que las técnicas de gestión ágiles en los proyectos promueve un enfoque sobre los beneficios de cada característica. En la gestión de proyectos tradicionales, los equipos se esfuerzan por terminar el proyecto a tiempo y bajo presupuesto y, a menudo, perder de vista los beneficios generales que todo el esfuerzo está destinado a llevaren una organización. De esta manera, los beneficios del proyecto van a ser obvios, si el equipo desarrolla una nueva solución de negocio.