Los 5 Objetivos

Publicado
por
Alberto Dominguez, PMP
el Junio 3, 2009
en Uncategorized
. 0 Comentarios

Estos objetivos genéricos de la gerencia de proyectos son independientes de la industria y, sin importar la experiencia, deberían ser considerados en sus proyectos.

Objetivo 1: Terminar a tiempo

Este es el más antiguo y enredado de los objetivos mencionados. Es el más difícil puesto que los requerimientos muy probablemente cambiaran durante el ciclo de vida del proyecto y, como nos pasa a todos, el cronograma original era en “algo” optimista.

Para garantizar el éxito deberá, como gerente de proyecto, gestionar el alcance con suma precaución. Implementar un proceso de control de cambios adecuado para incluir propiamente todos los nuevos requerimientos y cambios. Mantener siempre actualizado su plan de proyecto/trabajo, evaluar el progreso del proyecto (planeado vs. real). Identificar las desviaciones del plan y corregir el rumbo del proyecto lo más pronto posible.

Objetivo 2: No exceder presupuesto

Asegurar los costos del proyecto de acuerdo al presupuesto -o en muchos casos, por debajo- no es tarea fácil. Para ello establecer líneas base de presupuesto permitirán comparar y hacer seguimiento en todo momento a la ejecución de dicho presupuesto. Es muy importante incluir todos los costos relacionados con el proyecto, ya sea de forma directa o indirecta -como son entre otros: personal, equipos, proveedores, materiales. Esto logra que, al establecer el plan de ejecución -las tareas por hacer- se pueda asociar con mayor certeza un plan de ejecución presupuestal.

No debemos olvidar que es posible balancear el gasto realizado, si para algunas tareas tenemos sobrecosto y para otras ahorro.

Objetivo 3: Satisfacer los requerimientos

Este objetivo es intrínseco ya que es por los requerimientos que se definió el proyecto para el cual estamos trabajando o vamos a trabajar. Sin importar cuales sean estos requerimientos, nuestro objetivos como gerentes es garantizar que estos requerimientos se cumplen en un 100%.

El truco es garantizar que la información detallada de algunos requerimientos es suficiente al inicio de la ejecución. Si los requerimientos son ambiguos, de seguro existirán diferencias entre las expectativas e interpretaciones, y es ahi donde “un requerimiento” se convierte en todo un “subproyecto”, lo que en otros términos en una asignación de personas o consumo inesperado de recursos.

Objetivo 4: Hacer felices a los clientes

Es curioso pero cierto, usted puede terminar su proyecto a tiempo, dentro del presupuesto estimado y habiendo alcanzado el 100% de los requerimientos, y esto no garantiza que el resultado sea un cliente contento/agradecido. Esto se debe en la mayoría de los casos a que los requerimientos no concuerdan con las expectativas, y esto significa desde luego que las expectativas deben ser gestionadas de forma similar a los requerimientos.

Para garantizar que el patrocinador del proyecto (sponsor), los clientes y otros interesados (stakeholders) están contentos al final del proyecto, es vital gestionar y manejar las expectativas de cada uno de forma cuidadosa. Para ello, es importante mantener un contacto regular con ellos, informando sobre el avance. Este informe de avance no puede ser otra cosa más que real, claro y sencillo de entender. También es importante darles un espacio regularmente para comentar sus dudas e inquietudes. Y, desde luego, es importante poner la cara cuando se presenten problemas, retrasos, o se deban tomar decisiones importantes. La realidad, abierta y honesta, es siempre la mejor herramienta para gestionar las expectativas de los interesados.

Objetivo 5: Mantener un equipo alegre y motivado

Para terminar, si ha todos los objetivos anteriores les suma, la idea de lograrlos con un equipo alegre y motivado, no podemos esperar otra cosa que el interés de volver a trabajar juntos en el siguiente proyecto. Y así es como su equipo deberá sentirse al final del proyecto. La satisfacción del equipo es crítica para el éxito del proyecto.

Mantenga a su equipo de trabajo contento, recompensando sus éxitos y reconociendo el esfuerzo. Asigne el trabajo garantizando que aquellos que tienen la responsabilidad de hacer algo, tienen las competencias para hacerlo. Actividades de construcción de equipo (team building) son necesarias para elevar la moral del equipo. Con un equipo motivado y alegre es posible lograr todo objetivo.

Estos son, Los 5 Objetivos Genéricos que debe establecer para cada proyecto.

Artículo publicado por Method123 en su lista de correo -yo me tomé el tiempo de “traducirlo”.

Oficina de Proyectos

Publicado
por
Alberto Dominguez, PMP
el Mayo 6, 2009
en PMO
. 0 Comentarios

La oficina de proyectos es una unidad formal y permanente de las organizaciones, responsable de coordinar los proyectos, y asegurar la disponibilidad de las correctas herramientas -estándares, metodologías, plantillas de documentos, entre otros. 

Depende de la estructura y la naturaleza de la organización y del negocio, cómo y dónde se debe ubicar la oficina de proyectos a nivel jerárquico. Por ejemplo, esta puede puede hacer parte de la unidad de tecnología e informática de una compañía tradicional, cuya cadena de valor no esta soportada en proyectos (grandes superficies, manufactura de bienes de primera necesidad); o puede hacer parte estratégica de las unidades de negocio (empresas de construcción, de investigación, e incluso publicidad). Su ubicación dentro de la jerarquía de la organización incide directamente en la magnitud del impacto sobre la operación.

La cultura organizacional por su parte incide directamente en la postura que adoptará la recién creada oficina de proyectos frente a los proyectos nuevos y en curso. En una organización funcional, la capacidad de intervención de una oficina de proyectos es limitada, debido a que en la mayoría de los casos, no tiene el poder suficiente para incidir en las decisiones de las unidades funcionales, y por lo tanto la oficina de proyectos tendrá un cáracter orientado al soporte y resolución de elementos puntuales (oficina consultiva). En el caso contrario, una compañía proyectizada, tiene mayor oportunidad y espacio para constituir una oficina de proyectos en niveles gerenciales y/o estratégicos de la compañía, consolidando por su parte un herramienta de poder y persuación que le permitirá a la oficina ejercer labores directivas y de control más estrictas (oficina de dirección).

Postura PMO

 

Con el fin último de simplificar la implementación de una nueva oficina de proyectos, es necesario analizar las metodología existenes y su flexbilidad para adaptarse a la organización. Definir el proceso y los comportamientos de los individuos en el tiempo de vida de los proyectos hará todo más fácil de entender y transmitir. Metodologías, muchas, metodología aplicada en la organización, sólo una.

Un error común es pensar que el PMI es una metodología y que el PMBoK la describe, cuando en realidad, el PMBoK sólo describe todas aquellas herramientas contempladas dentro de las labores de administración y gestón de proyectos, que, en su momento serán evaluados por la organización para determinar su relevancia dentro del caso específico.

Las metodologías no son tampoco un producto de software, o un proveedor. Las metodlogías son los procesos definidos de las organizaciones, con claridad y certeza. Una metodología se asume estándar cuando varias organizaciones la implementan y soportan -caso puntual de PRINCE2, o el PPM, o incluso el mal conocido SDP21. Sin embargo, la implementación de una metodología, asistida de forma automática por un producto de software, es sin duda mucho mas simple que aquella que delega la responsabilidad administrativa de la información y su confiabilidad, en las personas que además deben interiorizar el cambio en los procesos.

Las oficinas de proyectos responden a las necesidades de las organizaciones, y en tiempos económicos difíciles, donde todos son susceptibles a cambios, estructuras de organización flexibles y proyectizadas tienden a emerger como alivio a la lentidud organizacional de la cual muchas empresas adolecen. 

Las 25 ciudades más peligrosas para hacer Offshore

Publicado
por
Alberto Dominguez, PMP
el Marzo 24, 2009
en Actualidad
. 0 Comentarios

Como les comenté hace algunos días durante la jornada de Gerencia de Proyectos, durante mi presentación hablamos sobre offshoring (tercerización), y comenté que Bogotá estaba catalogada como la ciudad más peligrosa del mundo para este tipo de negocios. ¿Cuiroso? ¿Cierto? ¿Claro? Juzguen ustedes. El reportaje completo esta publicado aquí @ CSO Online

Como les comenté, el simple hecho de que la ciudad se presente como Bogota, Columbia, me expresa el sentido de seriedad y veracidad del mismo.

El Manifiesto Ágil

Publicado
por
Alberto Dominguez, PMP
el Marzo 22, 2009
en Herramientas y Procesos y Procedimientos
. 0 Comentarios

En este blog he escrito casi siempre sobre modelos tradicionales de gerencia de proyectos como el PPM del PMI y la metodología PRINCE, si embargo, existe todo universo alrededor del tema de gerencia ágil de proyectos - Agile. Este es fundamentalmente un cambio general de concepción sobre la gerencia que tiene sus orígenes en la gerencia de desarrollo de software. Un conjunto de metodologías han sido modeladas y se sustentan en el supuesto fracaso de las metodologías tradicionales -y más aún en lo que ha desarrollo de software se refiere.

La concepción moderna de la gerencia ágil de proyectos surge a mediados de los 90’s como respuesta a las metodologías sobrecargadas que presentaban muchas falencias y un deterioro de la percepción y relación entre los clientes y los desarrolladores de software debido a, entre otras cosas, la regulación excesiva, el incorporado micro-management del modelo de desarrollo en cascada (waterfall) ,y extremadamente estricto. La excesiva burocracia y lentitud no era consecuente con la manera como los desarrolladores trabajan, por tanto el rendimiento y capacidad productiva se veía negativamente impactada.

El desarrollo de software era originalmente ágil, y por tanto la regulación excesiva del proceso puede, entenderse como una evolución inadecuada en busca de la perfección -que todos sabemos no existe en términos de software. Estos procesos definidos de desarrollo ágil originales eran conocidos como metodologías livianas y existían antes de los modelos pesados como SDP21 y CMM.

El Manifiesto Ágil

A inicios del 2001, varios detractores de los modelos tradicionales que habían apoyado y desarrollado metodologías livianas se reunieron y definieron lo que, en su momento los identificaba como un grupo. El resultado de esa reunión fue el documento conocido como el Manifiesto Ágil.

Estamos  poniendo  al  descubierto  mejores métodos  para  desarrollar  software,  haciéndolo  y ayudando  a  otros  a  que  lo  hagan.  Con  este trabajo hemos llegado a valorar:

  • A  los  individuos  y su  interacción, por encima de los procesos y las herramientas.
  • El  software  que  funciona,  por  encima  de  la documentación exhaustiva.
  • La colaboración con el cliente, por encima de la negociación contractual.
  • La  respuesta  al  cambio,  por  encima  del seguimiento de un plan.

Aunque hay valor en los elementos de la derecha, valoramos más los de la izquierda.

Apoyando el manifiesto se presentaron 12 principios mencionados a continuación:

  • Nuestra más alta prioridad es satisfacer al cliente a través de la entrega temprana y continua de software de valor
  • Son bienvenidos los requisitos cambiantes, incluso en etapas avanzadas del desarrollo. Los procesos ágiles se adaptan y aprovechan del cambio como ventaja competitiva para el cliente.
  • Entregar software que funcione frecuentemente, en periodos desde un par de semanas hasta un par de meses, con preferencia en escalas de tiempo breves.
  • Las personas del negocio y los desarrolladores deben trabajar juntos de forma cotidiana a lo largo del proyecto.
  • Proyectos definidos y llevados a cabo en torno a individuos motivados. Proveerles el ambiente y el respaldo que necesitan para realizar sus labores, y confiar en que son capaces de de realizar las tareas asignadas.
  • La forma más eficiente y efectiva de comunicar información al interior del equipo de desarrollo es mediante la conversación cara a cara.
  • El software que funciona es la principal medida del progreso.
  • Los procesos ágiles promueven el desarrollo sostenido. Los patrocinadores, desarrolladores y usuarios deben mantener un ritmo constante de forma indefinida.
  • La atención continua a la excelencia técnica enaltece la agilidad.
  • La simplicidad, definida como arte de maximizar la cantidad de trabajo no realizado, es esencial.
  • Las mejores arquitecturas, requisitos y diseños emergen de equipos auto-organizados -self-organized teams.
  • En intervalos regulares, el equipo reflexiona sobre formas de ser más efectivo y ajusta su conducta en consecuencia.

La gerencia ágil de proyectos se fundamenta en la iniciativa definida por los desarrolladores de software, y adopta el término trabajo ágil -agile work. Dentro de las metodologías ágiles utilizadas para gerencia de proyectos no asociados a desarrollo de software se encuentran Scrum y eXtreme Programming.

Más información:

Sobre la Jornada

Publicado
por
Alberto Dominguez, PMP
el Marzo 17, 2009
en Uncategorized
. 0 Comentarios

La semana pasada, el jueves 12 y el viernes 13 estuve participando de la VII Jornada de gerencia de proyectos de TI, y debo decir que fue excelente. Tal vez no es un evento de gran envergadura y mucha popularidad, pero definitivamente es excelente. Las conferencias variadas y enriquecedoras. Las historias y experiencias de los conferencistas que nos compartieron sus técnicas y tácticas en las labores gerenciales y de gestión, el tema de las competencias profesionales -que fue presentado de forma impecable por Dora Ariza, colaboradora del grupo de interés-  y las presentaciones de Hugo Estrada y Tony Johnson (invitado especial) hicieron de esta, la primera jornada a la cual asisto, un evento excelente.

Acostumbrado a los grandes eventos, con muchas horas para relacionarse -PR y networking-, calidad cuestionable en las presentación y de poca asistencia en las conferencias de la mañana, que es lo usual en el medio de la publicidad y el mercadeo, este evento pequeño y con un grupo muy interesado en el tema fue sin lugar a dudas enriquecedor.

Mis sinceras felicitaciones a Martha Juliana Ardila, a Beatriz Caicedo y en general a todo el grupo de ACIS que estuvo detrás de la logística del evento.

Dato curioso y una válida la anotación: ¡Es notable la falta de convocatoria del capítulo del PMI de “Santafé de Bogotá” que no tuvo la más mínima presencia!