“Gestionando” Proyectos de Proveedores

La externalización del trabajo del proyecto es más común hoy en día que nunca, sobre todo en TI más del 50% de los proyectos se hacen a través de un proveedor. Es muy común que las empresas contraten algún producto o servicio, en donde el “expertise” del mismo reside en el proveedor. La falta de técnicos calificados, la necesidad de centrarse en tareas operativas, la falta de recursos o gerentes de proyectos internos, hace que la empresa compradora tercerice la función de implementar el proyecto en el proveedor. Sin embargo, a pesar de que se subcontrate la planificación y ejecución del trabajo, no se puede externalizar por completo la obligación de asegurarse de que el proyecto avanza sin problemas. Mucha gente no está segura de lo que debe hacer cuando se les pide gestionar una relación de tercerización de un proyecto. Parte de la incertidumbre se debe a que algunos de los roles del proyecto se invierten cuando se subcontrata el trabajo a un tercero, explicamos esto en este artículo. Leer más aquí

Anuncios

El Analista de Negocio y su rol en el Proyecto

En el anuncio de la nueva certificación PMI-PBA, el PMI citó una estadística respecto de que se prevé que los trabajos de análisis de negocios aumenten un 19 % para 2022. En esa misma dirección el MBA y PMP Ori Schibi explica en sus charlas y eventos del PMI cómo incorporar el cada vez más valioso papel del analista de negocios (BA) en el proceso de gestión de las expectativas de los interesados, y las oportunidades de colaboración PM-BA para maximizar los beneficios relacionados con la comunicación, la comprensión de las necesidades de las partes interesadas, la gestión de riesgos, control de cambios y la gestión de calidad. Este artículo explica los conceptos de este autor y cómo se expande el rol del BA, aumentando su colaboración en el proyecto para lograr resultados más eficaces y con mayor eficiencia. Leer más aquí

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