Construyendo una Catedral

Las tareas diarias y metas a corto plazo no son lo suficientemente motivadoras como para alimentar el largo proceso de acciones que necesariamente se debe tomar para alcanzar los objetivos y estrategia final de un proyecto. Ya lo decía el célebre pensador español José Ortega y Gasset cuando afirmaba que “Sólo es posible avanzar cuando se mira lejos”. De ahí que se resalta la importancia que tiene para un gerente de proyecto conocer claramente la visión y objetivo final del mismo, algo motivador e inspirador. Sin embargo, el gerente de proyecto no debe descuidar el día a día y también deberá bajar al nivel de una planificación a corto plazo que significa formular uno o más planos (caminos de acción) para alcanzar las grandes metas y objetivos finales del proyecto. Para ello, es necesario evaluar las necesidades, las tareas y los recursos disponibles a fin de establecer una estrategia para implementar una acción y, posteriormente, poder direccionar y controlar. Lea más aqui

Anuncios

Four Techniques for Defining Project Scope

Cada equipo de software tiene su propio método de definir y controlar el alcance del proyecto y los miembros del equipo a menudo se quejan de la corrupción de un alcance interminable. Este artículo de Karl Wiegers está adaptado en base a su libro sobre Software Requirements y describe cuatro técnicas para definir correctamente el alcance de un proyecto de software, ofreciendo también algunos consejos para manejar la corrupción del alcance. Leer más aquí (en inglés)

Writing High Quality Requirements

Escribir los Requisitos de un proyecto no es una tarea fácil. No existe un enfoque simple, sobre todo cuando se refieren a requisitos o especificaciones de software. Los requisitos tradicionales de alta calidad (no ágiles) deben tener una gramática correcta, buena ortografía, frases bien construidas, y una organización lógica. Existen muchas especificaciones o requisitos tradicionales que utilizan una mezcla al azar de diferentes verbos: debe, debería, podría, sería recomendable, es deseable, es requerido, puede, podría, etc. Muchas de estas palabras se usan indistintamente en una conversación casual, pero esto puede llegar a ser confuso en una hoja de especificaciones. Se le deja al lector el problema de preguntarse si hay una distinción sutil pero importante entre estos diferentes términos o palabras clave. En este artículo, adaptado de un libro de Karl E. Wiegers sobre Requerimientos de Software, se presenta numerosas guías y estilos a tener en cuenta para escribir requisitos funcionales en forma tradicional. Leer el artículo

Malos requerimientos = Malos proyectos

El PMI publicó un informe sobre una reciente investigación titulado “Pulse of the Profession In-Depth Report: Requirements Management — A Core Competency for Project and Program Success” . El informe detalla los resultados de una investigación realizada para comprender mejor las necesidades de gestión de requerimientos en las organizaciones y cómo estas competencias se pueden mejorar para lograr aumentar las tasas de éxito en los proyectos, al mismo tiempo de reducir el riesgo. La mala gestión de requisitos está costando a las organizaciones 51 millones de dólares por cada mil millones gastados en sus iniciativas estratégicas, según la investigación realizada por el PMI. Conforme a dicha investigación, se recomienda centrarse en las personas, los procesos y la cultura, pues eso podría elevar la madurez en la gestión de los requisitos de proyectos y mejorar en gran medida sus resultados. En este artículo un resumen del documento y nuestra ampliación sobre diversos temas relacionados con dicha disciplina. Leer más aquí

Intersecting Project Management and Business Analysis

Los gerentes de proyecto experimentados saben que además de controlar costos y ajustarse al cronograma del proyecto, la gestión del alcance es una de las tareas más difíciles en la gestión de proyectos. El punto de vista de lo que define el éxito del proyecto ha ido más allá de la simple gestión de la triple restricción. Uno de los aspectos más importantes hoy en día es la gestión orientada a la satisfacción de las partes interesadas. Manejar las expectativas y dar forma a las percepciones a través de una comunicación efectiva es importante, pero la recopilación de requisitos eficaces en el inicio del proyecto es el paso clave que asegurará que el proyecto ofrezca lo que realmente se espera. En este sentido, el analista de negocios (BA) debe convertirse en un aliado clave y asesor del director del proyecto. La mayoría de los gerentes de proyecto no están entrenados en la disciplina de análisis de negocios, de modo que aprovechando eficientemente las habilidades que un analista de negocios puede ofrecer, se puede mejorar en gran medida la posibilidad de éxito del proyecto. Leer el artículo

Gestión de Requisitos: Nueva certificación del PMI

Como sabemos la organización PMI® permite mejorar y madurar el éxito de las organizaciones en la profesión de gestión de proyectos a través de sus normas reconocidas a nivel mundial, certificaciones, recursos, herramientas, investigación académica, publicaciones, cursos de desarrollo profesional y otras oportunidades. En un reciente anuncio, la institución hizo realidad algo que venía promulgando sobre nuevas ofertas en materia de “Gestión de Requisitos”. Esto terminó en el ofrecimiento actual de una nueva certificación en “Análisis de Negocio” el PMI Profesional Certification en Análisis de Negocios (PMI- PBA). Además anunció otros planes tales como el desarrollo de una “Guía Práctica de Análisis de Negocio” para este año, así como un “Practice Standard sobre Análisis de Requerimientos” para el próximo año. La primera pregunta que me vino a la mente fue el título de un post en Internet: ¿Necesitamos (otra) certificación de análisis de negocios?. Leer más aquí

Planificación y Estimaciones en los Proyectos

Planificar o no planificar ? Estimar o no estimar ? Hasta dónde trabajar en planificaciones y estimaciones en los proyectos, cuando el ámbito donde se aplicarán está lleno de ambigüedades, restricciones e incertidumbres ? Existe la manera ideal de planificar y hacer estimaciones en un proyecto ?. Una mirada crítica y realista acerca de la problemática de los diferentes métodos de Planificación y Estimaciones en los proyectos, junto con tendencias modernas sobre dichas prácticas provenientes de los ámbitos de TI, algunas de la cuales se aplican en la gestión tradicional de proyectos y otras son demasiado disparatadas. El artículo complementa y acerca de alguna manera, los enfoques expuestos en otros dos informes anteriores sobre planificación y estimaciones en metodologías ágiles y tradicionales. Leer más

L

El estratégico “NO”

Más que nunca, somos prisioneros de lo urgente. Todos los días, nos vemos afectados por reuniones de trabajo estériles, enormes cadenas de correo electrónico, pedidos imposibles o exigencias que van más allá de nuestro trabajo o alcance, en lugar de ocupar nuestro tiempo en el tipo de trabajo adecuado. Esto es producto de la falta de asertividad, cualidad que debe poseer todo Gerente de Proyecto y que implica saber decir “NO” cuando corresponde, dado que es la única alternativa para separar las urgencias o pedidos innecesarios de aquellas tareas que son verdaderamente importantes. Acceder al Artículo

El SOW – Declaración de Trabajo

El SOW es un documento del proyecto que nos sirve de entrada para redactar el Project Charter, bien sea redactado internamente dentro de nuestra organización; o proveniente de un cliente externo quien nos está solicitando un producto o servicio. El CSOW es el documento que redactamos desde nuestro proyecto en ejecución, para la compra o suministro de un producto o servicio de algún proveedor externo. Muchas veces en la práctica y en alguna literatura, se traduce SOW como “Scope of Work” y se lo asimila a la Declaración de Alcance de un proyecto. En este artículo nos referimos a sus características. Leer más

Definiendo Requerimientos: Tradicional vs. Caso de Uso vs. Historias de Usuario

He trabajado la mayor parte de mi vida con proyectos de IT utilizando metodología tradicional y últimamente tuve varias experiencias con la gestión ágil. En muchos casos, el uso de las historias de usuario parece ser un punto de fricción dado que no todos entienden su uso y sobre todo para aquellos analistas que provienen de métodos tradicionales terminan armando historias tan largas y detalladas que se asemejan a los requerimientos tradicionales. La pregunta común es “¿Cuáles son las diferencias entre los requisitos tradicionales, casos de uso, y las historias de los usuarios?” En este artículo trato de responder a esta inquietud. Verlo aquí