viernes, 17 de octubre de 2008

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.

viernes, 10 de octubre de 2008

¿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.

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