1.3: Iniciación, alcance y estructura del proyecto

Planear sin acción es inútil. La acción sin planeación es fatal. —Anónimo

Objetivos

Después de leer este capítulo, podrás

• Definir términos básicos relacionados con el inicio del proyecto y explicar cómo la fase de iniciación encaja en el ciclo de vida general de un proyecto
• Discutir la importancia de definir el “éxito” para un proyecto
• Describir los elementos de una carta de proyecto y explicar su papel en la fase de iniciación
• Explicar temas relacionados con el alcance del proyecto
• Distinguir entre desafíos adaptativos y técnicos
• Explicar la importancia de comprender el contexto de un proyecto y el potencial de que ese contexto cambie a medida que inicia el proceso de iniciación

Las grandes ideas en esta lección

• Para iniciar con éxito un proyecto, es necesario mirar hacia el futuro, a través de todo el ciclo de vida del proyecto y anticipar los muchos problemas que podría tener que enfrentar. Sólo entonces podrás definir claramente lo que significa el éxito para tu proyecto. Es esencial evitar un enfoque puramente geométrico de la iniciación, eso supone que simplemente responderás a eventos cambiantes a medida que ocurren, en lugar de intentar anticiparlos.
• De las tres limitaciones en la gestión de proyectos (alcance, presupuesto y horario), el alcance es el más difícil de precisar. Describirlo de manera clara y detallada requiere mucho esfuerzo. Durante el inicio, es necesario definir el alcance del proyecto lo más claramente posible, y luego refinarlo a medida que se desarrolla el proyecto y aprende más sobre el proyecto y las necesidades del cliente.
• El potencial de cambiar contextos significa que no hay dos proyectos iguales. Incluso si crees que recientemente has completado un proyecto idéntico, seguramente encontrarás que las externalidades y las diferencias de contexto te obligarán a alterar tu enfoque de alguna manera u otra.

3.1 Iniciación y ciclo de vida del proyecto

La física nos dice que la luz es a la vez partícula y onda. La gestión de proyectos tiene una naturaleza igualmente dual; es a la vez una serie de fases distintas con un principio y un final claros, y un proceso continuo y circular en el que cada final conduce a un nuevo comienzo. A lo largo de un proyecto, un gerente de proyecto exitoso se esfuerza por anticipar las condiciones cambiantes, en lugar de simplemente responder a ellas a medida que surgen.

Comencemos con la visión más tradicional, que describe la gestión de proyectos como una serie de fases secuenciales, con la iniciación del proyecto inmediatamente después de la selección del proyecto. Se puede pensar en estas fases, mostradas en la Figura 3-1, como la naturaleza de partículas de la gestión de proyectos.

Figura 3-1: Vista tradicional de la gestión de proyectos

Pero si bien el inicio del proyecto marca el inicio oficial de un proyecto, hacerlo bien también requiere mirar más allá de la etapa de elaboración hasta todo el ciclo de vida del resultado final del proyecto. Se puede pensar en esto como la naturaleza de onda de la gestión de proyectos. Como se ilustra en la Figura 3-2, la etapa de elaboración, en la que se inicia y ejecuta un proyecto, es una parte del ciclo más grande que incluye la etapa de operación/uso/cambio, en la que el cliente hace uso del proyecto; y la etapa de demolición, cuando el proyecto se retira para que pueda ser reemplazado por algo nuevo y mejor.

Figura 3-2: Para iniciar con éxito un proyecto, es necesario visualizar todo el ciclo de vida del resultado del proyecto (Fuente: John Nelson)

Tomando esta visión holística del ciclo de vida te animará a hacer mejores preguntas sobre lo que realmente significa “éxito” para tu proyecto. Por ejemplo, a medida que la sustentabilidad se convierte en una preocupación de ingeniería siempre presente, los gerentes de proyectos a menudo necesitan tener en cuenta los efectos ambientales a largo plazo al juzgar el éxito de Esto implica el uso de herramientas como las evaluaciones del ciclo de vida (ACV) para evaluar los “impactos ambientales potenciales de un producto, material, proceso o actividad” y para “evaluar una gama de impactos ambientales a lo largo del ciclo de vida completo de un sistema de producto, desde la adquisición de materiales hasta la fabricación, uso, y disposición final” (Agencia de Protección Ambiental de Estados Unidos n.d.).

Un análisis de ACV temprano en la fase de inicio puede ayudar a ampliar su visión de los efectos potenciales de un proyecto y a aumentar la gama de opciones que considere a medida que pone en marcha el proyecto. En la industria de la construcción, los ACV a menudo se centran en el uso de energía y agua del ciclo de vida de un edificio. En el desarrollo de productos, los LCA se utilizan para evaluar los impactos del procesamiento, producción, empaque y reciclaje de materias primas, entre otras cosas. Para un ejemplo interesante de un análisis de la industria de la confección, vea lo siguiente: “El ciclo de vida de un jean”.

Un ACV es solo una de las muchas formas de poner en marcha el proceso de adquisición de conocimiento que se desarrolla a lo largo de un proyecto. No es raro saber poco o nada de un proyecto al inicio. Para cuando termines, sabes todo lo que deseabas saber al principio, y has adquirido conocimientos que puedes llevar adelante a nuevos proyectos. Todo lo que aprendas sobre un proyecto es importante, pero la información que compilas durante la iniciación te prepara para responder a la incertidumbre del orden vivo que inevitablemente surgirá a medida que se desarrolle el proyecto. Puede animarte a mirar más allá de la fase de iniciación a todo el ciclo de vida del proyecto, y luego volver a dar la vuelta usando tus nuevos conocimientos para adoptar un enfoque más holístico para la iniciación del proyecto.

Una de las mejores formas de aprender sobre un proyecto es platicar con todos los involucrados:

• Interactúe con el cliente para aprender todo lo que pueda sobre lo que quiere del proyecto a largo plazo. Es decir, averiguar cómo define el cliente el valor del proyecto. Esté preparado para hacer muchas preguntas. En algunas situaciones, podría ser útil ver al cliente usar un producto para tener una mejor idea de las necesidades insatisfechas. Tenga en cuenta que los clientes no siempre saben exactamente lo que quieren, y puede que no se les haya ocurrido que puedan dar forma a su forma de pensar en torno al ciclo de vida del proyecto. Es posible que necesiten la ayuda de un gerente de proyecto informado, experimentado y sensible para formular sus objetivos.
• Piense ampliamente en quién es el cliente e incluya las necesidades del usuario final, el cliente final, en su pensamiento. Por ejemplo, si estás construyendo una nueva clínica, no te limites a que los ejecutivos de la HMO paguen por el edificio. Tómese el tiempo para hablar con las personas que realmente van a usar el edificio: médicos, enfermeras, técnicos, personal administrativo, trabajadores de mantenimiento y pacientes.
• Hable con las partes interesadas —las personas que se verán afectadas o que pueden afectar el proyecto— y preguntar sobre sus inquietudes y necesidades. Asegúrate de entender sus suposiciones básicas.
• Al igual que al identificar clientes, piense ampliamente en quiénes son los grupos de interés. El cliente y los usuarios finales son claramente interesados, al igual que el gerente que patrocina el proyecto y los miembros del equipo del proyecto. Pero no te olvides de vendedores, propietarios de recursos, funcionarios gubernamentales y organismos reguladores, y miembros de otros departamentos de tu organización. (Jordania 2012)

Hacer que estas conversaciones y análisis de necesidades sean una prioridad te dará una visión más amplia del ciclo de vida general de tu proyecto. Aunque, por supuesto, en el día a día de un proyecto, no puedes pasar cada minuto mirando hacia el futuro, tienes que prestar atención a las fases tradicionales de la gestión de proyectos, enfocándote en detalles como horarios y personal. Aun así, a medida que completas las tareas relacionadas con una fase, a menudo necesitas pensar en el futuro en tareas relacionadas con una fase posterior. El solapamiento significativo entre las diversas fases es común, como se muestra en la Figura 3-3. A menudo necesitarás mirar hacia atrás y revisar la información que recopilaste durante la fase de iniciación a medida que aprendes más sobre el proyecto.

Figura 3-3: Incluso en la visión tradicional de la gestión de proyectos, las fases de un proyecto a menudo se superponen

Recuerda, un proyecto es una actividad de adquisición de aprendizaje. En la mayoría de los casos, lo que sabes durante el inicio del proyecto es solo una pequeña fracción de lo que sabrás cuando termine el proyecto. Tienes que estar preparado para adaptarte a medida que aprendes más sobre tu proyecto.

3.2 El trabajo de iniciación

Durante la iniciación, normalmente creará el primer borrador de los siguientes ítems, que toman una visión de alto nivel del proyecto:

• carta del proyecto: Una “fuente de información única y consolidada” (Richter 2014) para la iniciación y planeación de proyectos. Describe sus conocimientos actuales sobre el proyecto e incluye información como los nombres de todas las partes interesadas, una declaración de las necesidades de su organización, el historial previo al proyecto, el propósito del proyecto, los entregables y los roles y responsabilidades. Una carta de proyecto también se llama a veces una declaración general del proyecto. Puede ser útil pensar en la carta del proyecto como un contrato entre el equipo del proyecto y los patrocinadores del proyecto.
• declaración de alcance: Un documento que define el alcance del proyecto. Definir alcances, que es realmente el corazón de la fase de iniciación, se discute en detalle en la siguiente sección.
• caso de negocios: Un “argumento, generalmente documentado, que pretende convencer a un tomador de decisiones para que apruebe algún tipo de acción. Por regla general, un caso de negocio tiene que articular un camino claro hacia un atractivo retorno de la inversión (ROI). En su forma más simple, un caso de negocio podría ser una sugerencia hablada... Para temas más complejos, un caso de negocio debe presentarse en un documento cuidadosamente construido. Un documento de caso de negocios debe examinar los beneficios y riesgos que conlleva tanto tomar la acción como, a la inversa, no tomar la acción. La conclusión debe ser un argumento convincente para la implementación” (TechTarget n.d.). Un caso de negocio aborda estas preguntas fundamentales: 1) ¿Por qué este proyecto? 2) ¿Por qué este proyecto sobre otro proyecto? y 3) ¿Por qué este proyecto ahora?

Tanto la carta del proyecto como la declaración de alcance suelen evolucionar a medida que se desarrolla el proyecto y se aprende más sobre los detalles del proyecto en la fase de planificación. Esto significa que a medida que trabajas en la fase de iniciación, siempre debes estar pensando en los siguientes elementos de la fase de planeación:

• estructura de desglose del trabajo (EDT): Una descripción de las tareas asociadas con los entregables del proyecto, a menudo en forma de diagrama de árbol. Una estructura de desglose del trabajo “muestra la relación de cada tarea con las demás tareas, con el conjunto y el producto final (meta u objetivo). Se muestra la asignación de responsabilidad e identifica los recursos requeridos y el tiempo disponible en cada etapa para el monitoreo y gestión de proyectos” (Diccionario de Negocios n.d.). Puedes descargar un archivo Excel con una plantilla para una estructura de desglose del trabajo aquí: Estructura de Desglose del Trabajo.
• Estructura de Desglose Organizacional (OBS): Una descripción del equipo del proyecto. En él se explica “quién informa a quién, los detalles de la jerarquía, y la estructura de reporte... Las estructuras de desglose organizacional normalmente se comunican visualmente mediante el uso de gráficas o tablas. Se enumera un proyecto o gerente general y debajo del PM se pueden crear varias divisiones, como desarrollo de productos, diseño, gestión de materiales y producción” (Bradley n.d.). Véase también matriz de asignación de responsabilidad (RAM) a continuación.
• paquete de trabajo: Un “grupo de tareas relacionadas dentro de un proyecto. Debido a que ellos mismos parecen proyectos, a menudo se les considera como subproyectos dentro de un proyecto más grande. Los paquetes de trabajo son la unidad de trabajo más pequeña en la que se puede desglosar un proyecto al crear su Estructura de Desglose del Trabajo (EDT)” (Wrike n.d.).
• matriz de asignación de responsabilidad (RAM): Un tipo de estructura de desglose organizacional en forma de cuadrícula que normalmente enumera las tareas del proyecto en la primera columna y las partes interesadas en la fila superior, con tareas asignadas a los diversos grupos de interés. Puedes usarlo para determinar si tienes suficientes recursos para un proyecto, y para registrar quién es el responsable de qué. Los RAMs vienen en varias formas, pero una de las más útiles es un cuadro responsable, responsable, consultar e informar (RACI), que designa la relación de cada parte interesada con cada tarea, utilizando las siguientes categorías: responsable (realmente hace el trabajo), responsable (tiene autoridad final sobre el actividad), consultada (disponible para proporcionar información sobre la actividad), o informada (se informa una vez concluida la actividad, muchas veces porque su propio trabajo depende de ella) (Doglione 2018). Puedes descargar una plantilla para una matriz RACI aquí: “Matriz de Asignación de Responsabilidad”. Para una breve introducción a los gráficos RACI, consulte esta página web: “Gráficos RACI”. (Un gráfico RACI a veces también se conoce como un gráfico de responsabilidad lineal).

Evite la mediocridad del promedio de ideas

A medida que te embarques en el aprendizaje sistemático que es el sello distintivo de la fase de iniciación, te encontrarás con muchas ideas sobre la mejor manera de lograr el éxito. Algunos pueden ser verdaderamente innovadores, mientras que otros son ligeras variaciones sobre lo mismo de siempre. Si la innovación es tu objetivo, entonces ten cuidado de no caer presa de la idea promediando —tomando un poco de una idea, y un poco de otra, y un poco de otra— sin comprometerte completamente con ninguna. Según Andrew Hill, en una entrada de blog sobre el tema, una forma de evitar el promedio de ideas “es crear una fuerte cultura de retroalimentación. Dar a los miembros del equipo entornos donde puedan señalar fallas en los proyectos actuales ayudará a cambiar su mente al modo de pensamiento crítico. La retroalimentación también le brinda una herramienta para ayudar a medir, detectar o predecir el fracaso de un proyecto. De esta manera, las ideas sobre las que eliges actuar nunca se ponen en piedra, constantemente están siendo reevaluadas y repensadas” (Hill 2016). Puedes leer la entrada completa del blog aquí: “Cómo evitar el promedio de ideas”.

3.3 Definición del éxito

Los gerentes de proyectos experimentados saben que necesitas comenzar rápido definiendo lo que significa “éxito” para tu proyecto y determinando cómo medirlo. Para lograrlo, es necesario platicar con las personas y organizaciones que determinarán si el proyecto es un éxito. Esto puede incluir clientes internos o externos, individuos o grupos con autoridad de aprobación, o grupos de clientes potenciales. Muchos proyectos platican cuando los ingenieros responsables dicen: “Cumplimos con nuestro objetivo. Seguimos el plan tal como estaba escrito” pero el cliente dice: “No proporcionaste lo que yo quería”.

Innumerables productos han sido lanzados y posteriormente descontinuados porque las especificaciones no coincidieron con las necesidades de los clientes. Un ejemplo es la versión 2013 de Facebook Home, una interfaz de usuario para el teléfono Android que convirtió a Facebook en la pantalla de inicio del usuario, eliminando las características, como docks y carpetas de aplicaciones, que a los usuarios de Android les encantan. ¿Cómo podría la compañía cometer un error tan grande? Según Business Insider, el equipo de desarrollo de Facebook Home, compuesto principalmente por usuarios de iPhone, “no estaba familiarizado con las características a las que un usuario normal de Android podría acostumbrarse, y podría no querer perder cuando instalaron Facebook Home” (Carlson 2013). Esta falta de conocimiento de las necesidades de los clientes tuvo resultados desastrosos. El precio del HTC First, el teléfono en el que llegó preinstalado Facebook Home, bajó de 99 a 99 centavos en pocas semanas (Tate 2013). En última instancia, la revista Time nombró al HTC First uno de los “momentos más tontos de la tecnología” para 2013 (McCracken 2013).

En la industria de dispositivos médicos, un producto desarrollado con éxito podría eventualmente considerarse un fracaso si el equipo de desarrollo subestima los obstáculos para lograr la certificación de la FDA. Y podemos buscar en los autos autónomos un ejemplo de cómo el éxito se extiende más allá del alcance más estrecho de la finalización del producto. Los autos autónomos existen, pero tienen que ser capaces de interactuar con éxito con conductores humanos impredecibles y necesitan contar con la aprobación gubernamental para convertirse en un proyecto exitoso.

En proyectos de capital, el costo total de propiedad (el total de costos directos e indirectos relacionados con la construcción y uso de un edificio) es crucial para determinar si un edificio es o no un éxito. Por ejemplo, si un edificio diseñado para su uso solo durante los Juegos Olímpicos termina siendo utilizado durante años después, los costos de mantenimiento del edificio probablemente crecerán exponencialmente, transformando un edificio supuestamente exitoso en un fracaso a largo plazo desde el punto de vista de la ciudad anfitriona. La clave es proyectar de manera realista la vida total del diseño del edificio. El costo de mantenimiento también juega un papel en la cuestión de si la construcción financiada por donantes puede considerarse un éxito. En tales casos, el éxito a menudo se define como la “gran inauguración” de la instalación cuando realmente debería definirse como una infraestructura operativa totalmente financiada.

Los gerentes de proyectos exitosos suelen ser muy específicos cuando definen el éxito del proyecto. Por el contrario, los nuevos gestores de proyectos cometen el error de ser demasiado generales. Sin embargo, ser específico no significa necesariamente ser longwinded. Al enfocarte en las necesidades del usuario final en lugar de generar un catálogo exhaustivo de requisitos físicos, proporcionarás una definición concisa y útil de “éxito” para tu proyecto. Al tomar este enfoque, Lee Evey, el gerente del proyecto de reconstrucción del Pentágono después del ataque del 11 de septiembre, pudo consolidar miles de páginas de especificaciones en “16 requisitos basados en el desempeño. Por ejemplo, su requisito de eficiencia energética era que el edificio no utilizara más de un número específico de BTU [Unidades Térmicas Británicas] para calentar y enfriar el edificio por año. Entonces correspondía a los equipos de diseño-construcción cumplir con el requisito dentro del presupuesto” (Rife 2005).

Éxito en Lean y Agile

Los gerentes de proyectos tradicionales tienden a definir el éxito en términos de completar un proyecto a tiempo y dentro del presupuesto. Pero Lean presume una definición más amplia de éxito, una que prioriza la eliminación de residuos y la maximización del valor, y en el proceso de construcción de lealtad del cliente que se extenderá a proyectos aún imprevistos. El enfoque incesante en eliminar los desechos en la corriente de valor tiene el efecto corolario de mantener los proyectos dentro del cronograma y dentro del presupuesto. También tiende a mejorar la calidad del producto final, agregando valor que realmente beneficiará al cliente. Para obtener más información, vea esta explicación exhaustiva de la historia y utilidad de Lean en la gestión de proyectos: “Los orígenes de la gestión de proyectos Lean”.

En el desarrollo ágil, un equipo coincide en su definición de éxito intermedio en forma de meta sprint en cada reunión de planeación. El éxito para todo el proyecto no se mide en términos de estar a tiempo y dentro del presupuesto. En cambio, en el espíritu del manifiesto Agile, el éxito significa entregar “software de trabajo frecuentemente”, software que el cliente realmente puede usar (Beedle et al. n.d.). En última instancia, el éxito en Agile significa entregar tanto software de trabajo como lo permitan el cronograma y el presupuesto. La entrenadora de Agile Angela Johnson explica su visión del éxito de Agile en esta interesante entrada de blog: “Definiendo métricas de éxito para una metodología de proyecto ágil

3.4 Creación de la Carta del Proyecto

Desarrollar la carta del proyecto es una de las partes más importantes del inicio del proyecto. Al incluir a todas las partes interesadas clave en el proceso de crearlo, ayudará a garantizar un acuerdo sobre lo que constituye el éxito del proyecto, las limitaciones relevantes (por ejemplo, tiempo y presupuesto) y la definición de alcance.

La forma exacta de una carta de proyecto variará de una organización a otra. En algunas empresas, la carta del proyecto es un archivo de hoja de cálculo; en otras, un archivo de documento. Encontrarás muchas plantillas para cartas de proyectos disponibles en la web. Según Managing Projects Large and Small: The Fundamental Skills for Delivering on Budget and On Time, una carta de proyecto típica contiene algunos o todos los siguientes:

• Nombre del patrocinador del proyecto
• Relación entre los objetivos del proyecto y metas organizacionales superiores
• Beneficios del proyecto para la organización
• Marco de tiempo esperado de la obra
• Descripción concisa de los entregables del proyecto (objetivos)
• Presupuesto, asignaciones y recursos disponibles para el equipo del proyecto
• Autoridad del gerente de proyecto
• Firma del patrocinador (Harvard Business School Publishing Corporation 2006, 2-3)

Por encima de todo, una carta de proyecto debe ser clara y específica sobre los objetivos del proyecto, es decir, sobre la definición de éxito. Los objetivos deben ser medibles, por lo que no hay confusión sobre si el proyecto es o no un éxito:

La ambigüedad en los objetivos puede llevar a malentendidos, decepciones y costosas reelaboraciones. Considere este ejemplo de un objetivo amplio: “Desarrollar un sitio web que sea capaz de proporcionar información y cumplimiento de productos rápidos, precisos y rentables a nuestros clientes”. Así es como un patrocinador podría describir el objetivo del proyecto en la carta. Pero, ¿qué significa exactamente? ¿Qué es “rápido”? ¿Cómo se debe definir la precisión? ¿Es aceptable un error en 1,000 transacciones o un error en 10,000 cumpliría con las expectativas del patrocinador? ¿En qué grado el sitio debe ser rentable? Cada una de esas preguntas debe ser respondida en consulta con el patrocinador y las partes interesadas clave. (Harvard Business School Publishing Corporation 2006, 4-5)

Pero si bien quieres ser específico sobre los objetivos del proyecto, ten cuidado de no detenerte en los detalles precisos sobre cómo lograrás esos objetivos:

Una carta reflexiva indica los fines pero no especifica los medios. Los medios deben dejarse en manos del gerente del proyecto, el líder del equipo y los miembros. Hacer lo contrario, es decir, decirle al equipo qué debe hacer y cómo hacerlo, socavaría cualquier beneficio derivado de haber reclutado a un equipo competente. (Harvard Business School Publishing Corporation 2006, 5)

Alcance en Ágil

Robert Merrill, analista de negocios sénior de la Universidad de Wisconsin-Madison, y coach de Agile, aconseja tomar un enfoque de tres partes para el alcance de los proyectos ágiles, determinando lo siguiente:

1. Características mínimas viables: si no podemos entregar tanto dentro de las limitaciones de horario y presupuesto, el proyecto debería cancelarse.
2. Características en las que no podemos pensar ahora, aunque estas pueden ser características que el cliente quiere, no son algo que podamos crear, por lo que no podemos perder tiempo y energía mental pensando en ellas.
3. Todo lo demás: este es nuestro búfer de imprevisibilidad, que mantenemos para proteger el cronograma y el presupuesto.

Tenga en cuenta que estas categorías no están congeladas; se pueden cambiar durante cada ciclo de planificación de iteraciones. El alcance en un proyecto Ágil es variable, pero manejado cuidadosa y visiblemente.

3.5 Gestión del alcance del proyecto

El tiempo, el costo y el alcance se conocen como las restricciones triples de la gestión de proyectos. No es posible cambiar uno sin cambiar al menos uno de los otros. Si el proyecto tarda el doble de lo esperado en completarse, entonces es casi seguro que el costo subirá. Por otro lado, una decisión de recortar costos, tal vez mediante el uso de mano de obra menos experimentada, podría llevar a una desaceleración laboral, extendiendo el horario. Tal decisión también podría resultar en un cambio en el alcance del proyecto, tal vez en la forma de un producto de menor calidad.

La fase de iniciación es demasiado temprana en el proyecto para concretar detalles precisos sobre el tiempo y el costo, pero es un buen momento para pensar mucho sobre el alcance, que es “todo el trabajo que hay que hacer para brindar el producto o servicio que su proyecto está entregando” (Martínez n.d.). En esta etapa temprana, usted y las partes interesadas del proyecto podrían hacer un poco de cielo azul pensando en lo que su proyecto podría lograr, sin tener en cuenta las limitaciones de tiempo, costo y alcance. Pero en poco tiempo necesitarás concentrarte en una definición del alcance del proyecto, formalizándolo como una declaración de alcance, utilizando la información actualmente disponible para ti.

Excepto por los proyectos más simples, es casi seguro que cualquier definición de alcance evolucionará a medida que aprendas más sobre el proyecto y las necesidades del cliente. El término evolución del alcance se refiere a los cambios en los que todos los interesados coinciden, y que van acompañados de los correspondientes cambios en el presupuesto y el calendario. La evolución del alcance es un resultado natural del tipo de aprendizaje que se desarrolla a medida que se desarrolla un proyecto, por ejemplo, el aprendizaje que surge de nuevos conocimientos sobre las necesidades del usuario final, nuevas regulaciones o trastornos en el mercado. Siempre y cuando todas las partes interesadas estén de acuerdo sobre los cambios de alcance (y los cambios asociados en el presupuesto y el cronograma), la evolución del alcance garantiza que los clientes realmente obtengan lo que quieren del proyecto. Cuanto más hables con el cliente y aprendas sobre sus necesidades, más podrás afinar el alcance.

En efecto, uno de los principales trabajos de un gerente de proyecto es gestionar la evolución del alcance. Pero diferentes tipos de proyectos implicarán cantidades variables de evolución de alcance. Por ejemplo, si estás trabajando en un proyecto relacionado con satisfacer una regulación ambiental específica, la definición inicial del alcance del proyecto podría ser clara, requiriendo poco refinamiento a medida que el proyecto se desarrolla, siempre y cuando la regulación en sí no se altere. Pero si está trabajando en un producto diseñado para satisfacer una nueva demanda del mercado, es posible que deba refinar el alcance continuamente para asegurarse de satisfacer las necesidades de sus clientes.

Quizás la causa más común de evolución del alcance sea un cambio en el contexto en el que se planifica y ejecuta un proyecto. Las alteraciones en las fuerzas del mercado, los cambios demográficos, la competencia nueva o más vigorosa y los avances tecnológicos pueden cambiar el contexto de un proyecto, obligándote a repensar su alcance. Este potencial para cambiar contextos significa que no hay dos proyectos iguales. Se podría pensar que el Proyecto B es casi idéntico al Proyecto A, pero luego un cambio repentino de contexto puede cambiarlo todo. Como se muestra en la Figura 3-4, el contexto se define en gran medida por las estructuras organizacionales, sociales y políticas en las que se desarrolla un proyecto.

Figura 3-4: El contexto está definido en gran medida por las estructuras organizacionales, sociales y políticas en las que se produce un proyecto

Si bien necesita mantenerse abierto a la posibilidad de evolución del alcance, es esencial resistir la fluencia del alcance, una cascada incontrolada de cambios en el alcance sin cambios autorizados correspondientes en el presupuesto y el horario. La diferencia entre los dos es la diferencia entre el cambio gestionado y el no administrado:

Éxito ≠ No hay cambios en el alcance del proyecto

En sus esfuerzos por evitar la fluencia del alcance, tenga cuidado de no cometer el error de equiparar el éxito del proyecto con completar el proyecto exactamente como se especificó originalmente en la declaración de alcance durante la fase de inicio. En las corrientes siempre cambiantes del orden vivo, la evolución del alcance suele ser necesaria y deseable. A medida que las partes interesadas del proyecto aprendan nueva información sobre el proyecto, naturalmente harán sugerencias sobre formas de alterar el plan original. Pero nunca temas, si tienen una comprensión clara de la definición de éxito del proyecto, podrán distinguir entre la evolución del alcance y la fluencia del alcance. Entonces, como gerente del proyecto, quieres asegurarte de que todos entienden de hecho el significado de “éxito”.

• La evolución del alcance es el cambio manejado. Se trata de una alteración aprobada en el alcance del proyecto que se produce a medida que los participantes del proyecto aprenden más sobre el proyecto. Se traduce en un cambio oficial en el alcance del proyecto y, por lo tanto, en el presupuesto o cronograma del proyecto, según lo acordado por todos los participantes en el proyecto. Este tipo de cambio gestionado es un resultado natural y racional del tipo de aprendizaje que se desarrolla a lo largo del transcurso de un proyecto. Es una elección consciente necesaria por la nueva información que le obliga a reconsiderar los elementos esenciales del proyecto para lograr el valor deseado del proyecto.
• La fluencia del alcance es un cambio no administrado. Es causado por cambios incontrolados en el alcance del proyecto. Dichos cambios pueden agregar valor desde la perspectiva del cliente, pero el tiempo, el dinero y los recursos consumidos por el cambio de alcance conducen a sobrecostos adicionales. La fluencia del alcance tiende a ocurrir poco a poco porque nadie está prestando mucha atención al alcance del proyecto. Por ejemplo, en un proyecto de remodelación de cocinas destinado a reemplazar encimeras y gabinetes, decidir en el último minuto reemplazar todos los electrodomésticos podría ser un ejemplo de fluencia del alcance.

Creación de una declaración Clear Scope

La clave para administrar el alcance es una declaración de alcance cuidadosamente elaborada, que debe ser clara y precisa. Los detalles de cómo planeas llevar a cabo un proyecto pueden ser vagos al principio, pero lo que quieres lograr debe ser perfectamente claro. La vaguedad puede llevar a pequeños cambios en el alcance del proyecto, que a su vez conducen a otros cambios, y así sucesivamente, hasta que el proyecto original ya no sea reconocible.

Redactar una declaración de alcance, el documento que define el alcance del proyecto, es una parte importante de la fase de iniciación. No obstante, según Brad Bigelow en un artículo para el Project Management Institute, “suele expresarse en términos cualitativos que dejan espacio para la interpretación y el malentendido. En consecuencia, suele ser la mayor fuente de conflictos en un proyecto” (2012, 1).

Para evitar tales problemas, los gerentes de proyectos experimentados se esfuerzan mucho en aprender lo que debe y no debe incluirse en el proyecto, y luego articular estos límites lo más claramente posible en forma de una declaración de alcance. Según Bigelow, este trabajo es esencial para asegurar el éxito de un proyecto: “Ningún alcance de proyecto puede estar completamente libre de confusión —libre de subjetividad y definiciones imperfectas— siempre y cuando los seres humanos estén involucrados. Por otro lado, también es muy improbable que cualquier proyecto sobreviva alguna vez a la iniciación si su alcance es completamente vago, indefinido y sujeto a expectativas impredecibles” (2).

Si el alcance está mal definido, entonces lo que está o no está dentro del alcance del proyecto se reduce a una cuestión de perspectiva. No en vano, estas “diferentes perspectivas... a menudo pueden ser la raíz de conflictos dentro de un proyecto” (2). Bigelow describe un proyecto en el que el equipo y el cliente ven las cosas de manera muy diferente:

Un equipo de proyecto puede, por ejemplo, proponer preparar tres prototipos para refinar los requisitos del cliente y reducir los riesgos de producción. El cliente podrá rechazar esta propuesta como fuera de alcance... Debido a que los prototipos son fungibles y no se considerarán productos terminados, el cliente puede negarse a considerarlos como entregables. Y si percibe que la creación de prototipos retrasa la producción final y consume recursos que podrían ser mejor utilizados, puede rechazar la actividad como fuera del alcance aceptable del trabajo del proyecto. (2)

Cuando el alcance está mal definido, satisfacer al cliente puede ser cada vez más difícil, con el equipo arrancándose y creando lo que piensa que quiere el cliente, solo para que le digan: “No, no es eso”.

Las opiniones varían exactamente sobre lo que debe incluir una declaración de alcance, pero al menos debe contener lo siguiente:

• Una breve justificación del propósito del proyecto, incluyendo un resumen de las necesidades de negocio que abordará el proyecto.
• Una explicación de los objetivos del proyecto.
• Criterios de aceptación que especifiquen las condiciones que el producto o servicio debe cumplir antes de que el cliente acepte los entregables.
• Entregables, que son “los bienes o servicios cuantificables que se prestarán al término de un proyecto. Los entregables pueden ser partes tangibles o intangibles del proceso de desarrollo, y a menudo se especifican funciones o características del proyecto” (Investopedia n.d.).
• Una explicación de cualquier cosa excluida del proyecto, es decir, una explicación de lo que está fuera de alcance para el proyecto. Esta lista debe ser “tan detallada como sea necesario para definir los límites del proyecto a todos los interesados” (Feldsher 2016).
• Restricciones, como presupuesto y cronograma.
• Supuestos, incluyendo cualquier cosa que actualmente crea que es verdad sobre el proyecto. También es útil incluir ideas “sobre cómo abordará la información incierta a medida que concibe, planifica y realiza su proyecto” (Portny n.d.).
• Una explicación de cualquier tecnología nueva o inusual que planeas usar a lo largo del proyecto. Esta no es una parte típica de una declaración de alcance, pero “es probable que los interesados aprecien la transparencia y se sientan más cómodos con el proyecto en el futuro” (Feldsher 2016).

Algunas ideas prácticas para trabajar con el alcance

Un gerente de proyecto exitoso es experto en guiar a los clientes, quienes simplemente pueden no saber lo que quieren hasta que lo ven. Para productos verdaderamente innovadores, es posible que los clientes ni siquiera puedan definir lo que quieren. Un adagio atribuido a Henry Ford resume esto claramente: “Si le hubiera preguntado a la gente qué quería, habrían dicho caballos más rápidos”. El Sony Walkman no fue creado para satisfacer ninguna demanda identificada de los consumidores de música portátil, sino en respuesta a una solicitud del cofundador de Sony, Masaru Ibuka, de una manera conveniente de escuchar ópera. Un diseñador de Sony se puso a trabajar en la solicitud especial, y el resultado fue uno de los productos más exitosos de Sony de todos los tiempos (Franzen 2014).

La perspectiva ágil sobre la fluencia del alcance

Agile da la bienvenida a los cambios en los requisitos del producto incluso al final del proceso En efecto, los fundadores de Agile hicieron de la apertura a los cambios tardías uno de sus “Principios detrás del Manifiesto Ágil”, que puedes leer aquí: “Principios detrás del Manifiesto Ágil”.

En este entorno de constantes iteraciones y revisiones, los desarrolladores de Agile tienen una perspectiva diferente sobre la fluencia del alcance. Una entrada de blog para OptiSol explica algunas formas de identificar lo que es y qué no es el alcance de fluencia en Agile. Hacer cambios “antes de que el equipo haya comenzado a pensar en los detalles” no se consideraría arrastramiento de alcance en Agile, ni reemplazaría una característica por otra, siempre y cuando la nueva función no agregue nuevo trabajo para el equipo. Sin embargo, cambiar una nueva característica por una característica que ya está completa es definitivamente una forma de fluencia de alcance, porque crea un nuevo trabajo. Lo mismo es cierto de reemplazar una pequeña característica por algo más complejo (OptiSol n.d.). Puedes leer la entrada completa del blog aquí: “¿Qué es Scope Creep en el Desarrollo Ágil? ”

Cuando los desarrolladores de Facebook presentaron Facebook Home, pensaron que estaban guiando a sus clientes hacia una nueva forma de usar sus teléfonos móviles, así como Sony guió a sus clientes hacia una nueva forma de escuchar música. Pero debido a que los desarrolladores de Facebook sabían muy poco sobre las necesidades de sus clientes que usaban Android, terminaron creando un producto inútil. La moraleja de la historia: antes de intentar guiar a tus clientes, asegúrate de entender sus necesidades.

Aquí hay algunos otros consejos a tener en cuenta al pensar en el alcance:

• Los ingenieros tienden a enfocarse demasiado en lo que saben, con poca consideración a lo que no saben. Tómate un tiempo para pensar en lo que sabes que no sabes. Entonces trata de imaginar cómo lidiarías con los posibles riesgos que esas incógnitas podrían conllevar.
• Los ingenieros suelen ser personas muy detalladas. Esto puede ser un problema durante el inicio del proyecto si te obliga a trazar cada detalle del proyecto sin tener en cuenta el panorama general. Por supuesto, los detalles son importantes, pero también hay que tomar una visión de alto nivel al principio. No todos los detalles son de igual importancia y los detalles que son importantes pueden variar con el tiempo.
• Los ingenieros tienden a enfocarse en hacer en lugar de pensar. Les gusta saltar de inmediato y comenzar a ejecutar un proyecto. Pero recuerda que la iniciación del proyecto es tu momento de pensar un poco primero. La definición de alcance, en particular, es un proceso de pensamiento en el que se intenta conceptualizar lo que no se sabe.
• No todos los requisitos del proyecto son iguales. Pueden ir desde “absolutamente necesario”, hasta “me gustaría tener”. Al discutir los requisitos con el cliente, asegúrese de comprender dónde encaja cada requisito en esta escala.
• Haga al cliente tantas preguntas diferentes como sea posible sobre el proyecto. “Al sondear los requisitos y expectativas del cliente desde tantos ángulos como sea posible, un equipo de proyecto puede reducir significativamente el número de elementos inciertos del alcance del proyecto y reducir la variabilidad potencial de estos elementos. No garantiza que no se produzcan conflictos sobre el alcance del proyecto, pero puede ayudar a aislar las fuentes potenciales de estos conflictos” (Bigelow 2012, 4).
• Los mejores gerentes de proyectos entienden la importancia de aprender todo lo que puedan sobre la definición de “valor” y “éxito” de sus clientes, y luego sugieren formas de lograr esos objetivos que van más allá de lo que sus clientes podrían imaginar. Dichos gerentes de proyecto se enfocan en los requisitos de desempeño y las opciones para lograrlos, y evitan bloquear un enfoque demasiado rápido.
• A medida que el proyecto avanza más allá de la iniciación y en la planificación y ejecución, recuerde revisar la definición de alcance del proyecto regularmente para asegurarse de que sigue siendo apropiada. A medida que el proyecto avanza y las partes interesadas aprenden más sobre él, los cambios de alcance suelen ser inevitables. “En efecto, el fracaso de un proyecto para dar cabida a un cambio de alcance puede tener consecuencias mucho más graves para la organización en su conjunto que si el cambio hubiera sido aceptado—aunque el cambio aumentara el presupuesto del proyecto y ampliara su cronograma. La capacidad de un proyecto para adaptarse a tales cambios puede marcar una diferencia crucial en su valor final para la organización. Después de todo, los objetivos del proyecto están subordinados a los de la organización, no al revés. Por lo tanto, es crucial que el equipo del proyecto entienda al inicio mismo de un proyecto: ¿cuál es más importante? ¿Evitar el cambio o manejarlo?” (Bigelow 2012, 6).
• Un riesgo es especificar un producto que tenga las mejores características de cada competidor del mercado, por ejemplo, diseñar un motor industrial con la huella más pequeña posible, la mayor eficiencia, el menor costo, el mayor torque y todos los accesorios disponibles en el lanzamiento. El mero intento de superar a la competencia en especificaciones impide que un equipo busque una solución innovadora.
• Los equipos que definen con éxito el alcance del proyecto suelen comenzar por dedicar tiempo a ver a los clientes usar los productos o servicios relevantes.

3.6 Desde las trincheras: Michael Mucha sobre sustentabilidad y desafíos adaptativos

Michael Mucha es ingeniero jefe y director del Distrito Metropolitano de Alcantarillado de Madison, se desempeña como presidente actual del Comité de Sustentabilidad de ASCE y también forma parte de la Junta Directiva de Sustaind Dane en Madison, Wisconsin. Explica que el alcance de un proyecto está determinado por el tipo de problema que intentas resolver. ¿Es técnico, con una solución clara para la que tradicionalmente se capacita a los ingenieros? ¿O es adaptativo, sin un consenso definitivo sobre cómo proceder, con todas las soluciones garantizadas para desafiar los valores y creencias de las partes interesadas? ¿O es una mezcla de ambos?

Las soluciones de ingeniería sustentables a menudo implican desafíos adaptativos. A modo de ejemplo, describe un proyecto reciente:

Necesitábamos mejorar una estación de bombeo de aguas residuales entre la rampa para botes Marshall Park de Madison y un concurrido carril bici. Construir la estación en sí era un problema técnico. Si estuviéramos trabajando en un vacío total, podríamos haberlo construido de cierto tamaño y capacidad y haberse hecho con él. Pero para construir esta estación de bombeo en una zona tan concurrida, una sobre la que la gente tenía fuertes sentimientos, tuvimos que adoptar un enfoque adaptativo. Esto significó enfocarse en brindar beneficios sociales, como baños públicos, dos bocas de lavado de embarcaciones de especies acuáticas invasoras y una estación de reparación de bicicletas. Pero también trabajamos para educar al público sobre la mayor importancia del tratamiento de aguas residuales. Por ejemplo, una forma sencilla de llamar la atención de alguien es explicarle que, al descargar el inodoro, el agua viaja al Golfo de México en 40 días. Una vez que lo sepa, es posible que se sienta inclinado a ver una estación de bombeo como parte de una historia más amplia, una forma de ayudar a proteger el medio ambiente global.

En otras palabras, el problema pasó de un desafío técnico a otro adaptativo. Construir una estación de bombeo es muy directo. Podrías deletrear todos los pasos en un manual. Esa es la parte técnica. Pero no existe un manual para resolver un problema adaptativo. Implica cambiar las creencias y los valores de las personas. En el caso de la estación de bombeo, queríamos cambiar las ideas de la gente sobre cómo piensan sobre las aguas residuales, para que vean el trabajo en la estación como parte de algo más grande. (Mucha 2017)

La distinción entre problemas adaptativos y técnicos fue explicada por primera vez por Ronald A. Heifetz en su libro de 1998 Liderazgo sin respuestas. Para una introducción práctica y práctica al tema, Mucha recomienda La práctica del liderazgo adaptativo (Heifetz, Linsky y Grashow 2009).

3.7 Contexto del proyecto

Las realidades de las externalidades

Un término estrechamente relacionado con el contexto es la externalidad. Se refiere a una “consecuencia de una actividad económica que es experimentada por terceros no vinculados” (Investopedia n.d.). Una externalidad puede implicar “una pérdida o ganancia en el bienestar de una parte resultante de una actividad de otra parte, sin que haya compensación alguna para la parte perdedora” (Business Dictionary n.d.). Por ejemplo, una subida repentina de los precios del petróleo podría ser una externalidad devastadora en un proyecto que depende de un suministro constante y económico de combustible. Algunas externalidades son positivas, por ejemplo, la decisión de Irlanda de hacer que la educación universitaria pública sea esencialmente gratuita para todos los ciudadanos hizo que una fuerza laboral ya altamente educada fuera aún más atractiva para las empresas farmacéuticas y de software, lo que incrementó su inversión en el país (Friedman 2005).

Tú y tu equipo de proyecto no tienen control sobre las externalidades. Pero tu trabajo, como gerente de proyectos, es estar al pendiente de ellos a cada paso, y responder rápida y decisivamente cuando lo hacen.

Según Merriam-Webster, el término contexto se refiere a “la situación en la que algo sucede: el grupo de condiciones que existen dónde y cuándo sucede algo”. Todos los proyectos ocurren dentro de múltiples contextos, dentro de un contexto organizacional (tanto el suyo como el del cliente), un contexto de mercado, un contexto técnico y un contexto social. Todos estos pueden cambiar a lo largo de la vida de un proyecto, y en las aguas bravas permanentes del mundo empresarial moderno, probablemente lo harán. Los buenos gerentes de proyectos prestan atención al cambio de contexto. Se dan cuenta de que, a medida que cambian los contextos, probablemente habrá que ajustar el proyecto. Completar el proyecto de acuerdo con los objetivos originales podría terminar siendo un desenlace terrible, si resulta que los objetivos originales ya no se ajustan al contexto de la organización.

El potencial para cambiar contextos significa que no hay dos proyectos iguales. Incluso si crees que recientemente has completado un proyecto idéntico, seguramente encontrarás que las diferencias de contexto te obligarán a alterar tu enfoque de una forma u otra. Por ejemplo, el hecho de que hayas construido exitosamente un hospital en Detroit no te puede preparar completamente para la experiencia de construir un hospital en San Francisco, donde la actividad sísmica volátil de la zona significa que debes considerar una serie de temas relacionados con la resistencia a los sismos. En el desarrollo de productos, es posible que encuentre que el cliente no entendió completamente sus necesidades desde el principio. A medida que comienzas a aprender lo que quiere el cliente, es posible que veas el proyecto en un contexto mucho más amplio y complicado. De igual manera, la introducción de nuevas tecnologías puede aumentar la complejidad de un proyecto de maneras que no podías prever durante la iniciación. Para hacer frente a estos cambios, es necesario poder confiar en un equipo de proyecto flexible que pueda adaptarse a medida que se desarrolla el proyecto.

Un artículo de James Kanter en el New York Times describe la construcción de dos centrales nucleares europeas que se suponía que eran “clones” entre sí, ambas construidas de acuerdo con estándares rígidos especificando cada aspecto de los proyectos hasta “la alfombra y el papel tapiz”. Se suponía que la similitud de los proyectos llevaría a una navegación clara para ambos, pero una serie de problemas técnicos imprevistos resultaron en grandes retrasos y sobrecostos. Este es un ejemplo perfecto de cómo los contextos —un reactor estaba en Finlandia y el otro en Francia— pueden afectar dramáticamente los resultados de proyectos supuestamente idénticos. Los problemas en el sitio finlandés incluían una base demasiado porosa y por lo tanto probable que se corroa, subcontratistas inexpertos perforando agujeros en los lugares equivocados y problemas de comunicación derivados de una fuerza laboral compuesta por personas que hablan ocho idiomas diferentes. En el sitio supuestamente idéntico francés, una serie diferente de problemas incluyeron grietas en la base de concreto, refuerzos de acero colocados incorrectamente y soldadores no calificados. Según UniStar Nuclear Energy, la compañía detrás de los proyectos finlandés y francés, una flota de reactores similares se encuentran en proceso en todo el mundo. Quién sabe qué riesgos surgirán en esos proyectos. Después de todo, Francia y Finlandia son al menos estables, geológicamente hablando. Pero como señala Kanter, “los riesgos de terremotos en lugares como China y Estados Unidos o incluso la amenaza de marejadas de tormenta significa que construir estos reactores será aún más complicado en otros lugares” (2009).

El contexto es especialmente importante en el desarrollo de productos, donde el contexto de un nuevo producto puede cambiar de la noche a la mañana. En un artículo que defiende un enfoque más flexible para el desarrollo de productos, M. Meißner y L. Blessing discuten las muchas formas en que el contexto influye en el proceso de desarrollo del producto:

Los diseñadores están influenciados por la sociedad en la que viven, y sus decisiones dependen de presiones políticas, sociales y financieras. El entorno tecnológico y el ritmo acelerado de cambio es una característica de los tiempos modernos. Las condiciones cambiantes producen nuevas necesidades y, por lo tanto, fomentan nuevos desarrollos, se premia la innovación y se crean nuevos artefactos. Algunos productos requieren actividad de diseño a una escala mucho mayor que otros.

Enormes productos únicos como plantas de energía o plataformas petroleras requieren una operación de diseño inmensa y hábilmente organizada. Productos menos complejos como herramientas manuales o juguetes pueden ser diseñados por una sola persona... El diseñador podría estar trabajando en una pequeña empresa, llevando una variedad de responsabilidades, incluyendo la comercialización, diseño y fabricación del producto. O podría estar trabajando en una empresa más grande donde mucha gente trabaja en un solo proyecto de diseño con áreas específicas de actividad y una jerarquía de responsabilidades. (70)

En contextos cambiantes, la flexibilidad es clave. En sus estudios de gerentes de proyectos exitosos, Alexander Laufer encontró que los mejores gerentes de proyectos

desviarse del enfoque común de “una mejor manera” y ajustar sus prácticas al contexto específico de su proyecto. Evitar el enfoque de “una mejor manera” no implica, sin embargo, que no haya “caminos equivocados”, que “todo vale”, o que siempre debes “empezar de cero”. Siempre existe la necesidad de lograr un equilibrio entre confiar en el conocimiento acumulado de la organización, por un lado, y potenciar la flexibilidad y creatividad dentro de cada proyecto individual por el otro. (216)

Laufer sostiene que los gerentes de proyectos modernos necesitan emplear un enfoque moderno y más flexible que sus predecesores:

El modelo clásico de gestión de proyectos, en el que se desarrollan estándares para prácticamente todas las situaciones, espera que el gerente del proyecto sirva principalmente como controlador: garantizar que los miembros del equipo se adhieran al estándar establecido. Esta función conlleva sólo un mínimo requisito de juicio y ningún requisito de adaptación. En realidad, el gerente del proyecto debe dedicarse constantemente a dar sentido a la situación ambigua y cambiante, y debe ajustar las prácticas comunes a la situación única. Este proceso requiere una gran cantidad de interpretación y juicio basado en una rica experiencia. (218)

En la Lección 5, hablaremos sobre el valor de construir equipos diversos que reúnan a personas con habilidades complementarias, idealmente, personas de diferentes edades y niveles de experiencia. Pero, ¿cómo pueden los nuevos gerentes de proyectos, que carecen de esa “rica experiencia” tan importante, aumentar su comprensión general de los múltiples contextos de sus proyectos? Comienza investigando proyectos pasados con características similares, consultando con mentores y, en general, verificando tantas fuentes formales e informales sobre lecciones aprendidas de proyectos anteriores como puedas encontrar. También ayuda a mantenerse bien informados sobre su organización, sus clientes, su industria y el mundo en general. Por ejemplo, si estuvieras trabajando en un proyecto de construcción en el campo de la salud en la última década, habrías experimentado un cambio pronunciado en el contexto, lejos de un sistema centrado en el médico a un sistema centrado en el paciente que busca empoderar a los pacientes para definir valor en sus términos (Porter y Lee 2013). Si fueras nuevo en la gestión de proyectos en ese campo, sería prudente aprender todo lo que pudieras sobre ese cambio. En el orden vivo, tales cambios sísmicos son la norma, no la excepción, en casi todas las industrias.

~Consejos prácticos

• Involucrar a todas las partes interesadas: Tu objetivo es mantener a las personas involucradas significativamente en tu proyecto. No quieres que las partes interesadas se presenten a las apariciones ceremoniales en las reuniones del proyecto. En cambio, quieres que estén seriamente enfocados en las perspectivas de éxito del proyecto.
• Claridad de resultados: Pídele a tu cliente que defina el éxito desde el principio. Luego, trabajando con el cliente y otros grupos de interés, definir cómo se medirá el éxito.
• Usa un vocabulario común: Al inicio de cualquier proyecto, acude a tus clientes finales y aprende su vocabulario. Asegúrate de entender los términos que son importantes para ellos y lo que esos términos significan para ellos. Siempre que sea posible, usa el vocabulario de tu cliente, no el tuyo. Además, esfuércese por hablar en inglés sencillo siempre que pueda, y evite hablar tecno.
• Crear un glosario de términos: En proyectos con mucha jerga compleja, considere crear un glosario de términos. Después publícalo de una manera que lo haga accesible a todos los interesados, actualizándolo según sea necesario. He aquí un ejemplo de uno de esos glosarios: “Marco COSO. ”
• Identifica lo que no sabes: Cuando comienzas un proyecto, siempre hay cosas que no sabes. La clave es saber que no los conoces. Cuanto más se esfuerce por reconocer esto, mejor será para predecir esas incógnitas y hacer provisiones para ellas.
• Hacer que los miembros clave del equipo firmen documentos importantes del proyecto: La investigación muestra que el acto de firmar un documento hace que la gente se comprometa mucho más a cumplir con las promesas descritas en el documento. Considere pedirle a todo el equipo del proyecto que firme la carta del proyecto y los documentos de alcance. Este simple acto puede servir como un poderoso incentivo para completar el proyecto con éxito.
• Concurrencia proactiva: En las primeras etapas, evite la trampa de trazar una cosa tras otra, de manera lineal. En cambio, empieza rápido, haciendo tantas cosas como puedas al mismo tiempo, lo más rápido que puedas. Esto le dará una idea de si el alcance, el presupuesto, los recursos y el cronograma están en alineación relativamente estrecha en la escala macro. Si encuentra que no lo son, reportarlo a la dirección de inmediato.
• Urgencia permanente: En el orden de vida en el que se desarrollan todos los proyectos modernos, la urgencia permanente es la nueva ley de la naturaleza. En la forma tradicional de orden geométrico de la gestión de proyectos, se podría suponer que tendría tiempo y recursos suficientes para hacer las cosas de manera lineal, paso a paso. Pero en el mundo moderno, ese rara vez es el caso. Acostúmbrate a un elemento de urgencia en todos los proyectos. Intenta no dejar que esto te paralice a ti y a tu equipo. En su lugar, deje que un sentido de urgencia lo impulse hacia técnicas de gestión de proyectos más ágiles, alertas y flexibles.
• Publica los documentos del proyecto de manera destacada: Poner documentos importantes al frente y al centro ayuda a que un equipo se mantenga enfocado, especialmente si tienes a todos los que los firmen primero. También alienta al equipo a actualizarlos cuando sea necesario.
• Planificar errores: Usted y su equipo cometerán errores casi seguros, especialmente en las primeras etapas de un proyecto. Así que planifica para eso. Sigue pensando en lo que podría salir mal, y cómo podrías corregir el rumbo. Acostúmbrese a guardar los planes de respaldo en su bolsillo trasero.
• Definir criterios de firma o aceptación: Una buena manera de lograr que se defina el éxito es comenzar por elaborar criterios de cierre de sesión, o criterios de aceptación como a veces se les llama. Estos son entregables acordados para cada etapa clave del proyecto que permite que la etapa se considere completa. Es común vincular estos criterios a los pagos. El valor de estos criterios que se definen al principio es que suelen ser muy objetivos y pueden ser referidos continuamente, asegurando así que todas las actividades estén alineadas con los entregables finales. Los desacuerdos importantes sobre si un proyecto fue un éxito generalmente se reducen a la falta de definición de los criterios de aceptación. Lograr un acuerdo sobre esto es fundamental, ya que impulsa todo lo demás (recursos, tiempo, presupuestos, etc.).
• Prepárate para el cambio: No te dejes engañar pensando que, solo porque has creado todos los documentos asociados al inicio del proyecto, tienes todo clavado. A menudo no es posible prever los tipos de cambios continuos que surgen en el orden vivo.

~Resumen

• El inicio del proyecto consiste en sentar las bases para todo el proyecto. Aunque la iniciación marca el inicio oficial de un proyecto, implica mirar hacia el futuro, vislumbrar todo el ciclo de vida del proyecto, que incluye la etapa de elaboración, la etapa de operación/uso/cambio y la etapa de retiro/reutilización. Incluso en la forma más tradicional de mirar la gestión de proyectos, las fases de la gestión de proyectos suelen superponerse y a menudo implican mirar hacia atrás en los documentos recopilados durante la fase de inicio.
• Estos documentos creados durante la iniciación suelen proporcionar una visión de alto nivel del proyecto. Incluyen la carta del proyecto, la declaración de alcance y el caso de negocio. A medida que cree estos documentos, debe estar pensando en crear los siguientes elementos durante la fase de planeación: estructura de desglose del trabajo (EDT), estructura de desglose organizacional (OBS), paquete de trabajo y la matriz de asignación de responsabilidad (RAM).
• Los gerentes de proyectos experimentados saben que necesitas comenzar rápido definiendo lo que significa “éxito” para tu proyecto y determinando cómo medirlo. El éxito significa cosas diferentes en diferentes industrias. Por ejemplo, en proyectos de capital, el costo total de propiedad (el total de costos directos e indirectos relacionados con la construcción y uso de un edificio) es crucial para determinar si un edificio es o no un éxito. Sea lo más específico posible a la hora de definir el éxito de su proyecto, sin entrar en detalles innecesarios. Los gerentes de proyectos tradicionales tienden a definir el éxito en términos de completar un proyecto a tiempo y dentro del presupuesto. Pero Lean presume una definición más expansiva del éxito, una que prioriza la eliminación del desperdicio y la maximización del valor, y en el proceso de construcción de la lealtad del cliente que se extenderá a proyectos aún imprevistos. En Agile, el éxito significa entregar software de trabajo después de cada sprint y, en última instancia, entregar tanto software de trabajo como permita el horario y el presupuesto.
• Una carta de proyecto bien definida define los objetivos del proyecto, que a su vez dictan la organización general, el horario, el personal y, en última instancia, el trabajo que se logrará.
• De las tres limitaciones en la gestión de proyectos (alcance, presupuesto y horario), el alcance es el más difícil de precisar. Excepto por los proyectos más simples, es casi seguro que cualquier definición de alcance evolucionará a medida que aprendas más sobre el proyecto y las necesidades del cliente. El término evolución del alcance se refiere a los cambios en los que todos los interesados coinciden, y que van acompañados de los correspondientes cambios en el presupuesto y el calendario. En última instancia, la definición de alcance se basa en lo que el cliente quiere, pero a veces necesitarás guiar al cliente hacia una definición del alcance del proyecto porque es posible que el cliente no sepa lo que es posible. Tómese el tiempo para articular cuidadosamente el alcance en forma de declaración de alcance. Después de crear una declaración scope, consulte regularmente para evitar los cambios no autorizados conocidos como scope fluencia.
• El alcance de un proyecto está determinado por el tipo de problema que intentas resolver. Los problemas técnicos tienen soluciones claras: los ingenieros del tipo tradicionalmente están capacitados para proporcionar. Con los problemas adaptativos, las cosas son menos claras, sin un consenso definitivo sobre cómo proceder, y con cualquier solución garantizada para desafiar los valores y creencias de las partes interesadas. Algunos problemas son una mezcla de ambos.
• Todos los proyectos ocurren dentro de múltiples contextos, dentro de un contexto organizacional (tanto el suyo como el del cliente), un contexto de mercado, un contexto técnico y un contexto social. Todos estos pueden cambiar a lo largo de la vida de un proyecto, y en las aguas bravas permanentes del mundo empresarial moderno, probablemente lo harán. Un proyecto necesariamente evolucionará a medida que cambie el contexto del proyecto. Tu trabajo como gestor de proyectos es estar atento a las externalidades que puedan afectar el contexto de un proyecto.

~Glosario

• caso de negocios —Un “argumento, generalmente documentado, que pretende convencer a un tomador de decisiones para que apruebe algún tipo de acción. El documento en sí es a veces referido como un caso de negocio. Por regla general, un caso de negocio tiene que articular un camino claro hacia un atractivo retorno de la inversión (ROI). En su forma más simple, un caso de negocio podría ser una sugerencia hablada... Para temas más complejos, un caso de negocio debe presentarse en un documento cuidadosamente construido. Un documento de caso de negocios debe examinar los beneficios y riesgos que conlleva tanto tomar la acción como, a la inversa, no tomar la acción. La conclusión debe ser un argumento convincente para la implementación” (TechTarget n.d.).
• contexto —Según Merriam-Webster, la “situación en la que algo sucede: el grupo de condiciones que existen dónde y cuándo sucede algo”.
• idea promediando —Tomando un poco de una idea, y un poco de otra, y un poco de otra— sin comprometerse completamente con ninguna.
• gráfico de responsabilidad lineal — Ver gráfico RACI.
• estructura de desglose organizacional (OBS) — Una descripción del equipo del proyecto. En él se explica “quién informa a quién, los detalles de la jerarquía, y la estructura de reporte... Las estructuras de desglose organizacional normalmente se comunican visualmente mediante el uso de gráficas o tablas. Se enumera un proyecto o gerente general y debajo del PM se pueden crear varias divisiones, como desarrollo de productos, diseño, gestión de materiales y producción” (Bradley n.d.). Véase también matriz de asignación de responsabilidad (RAM), a continuación.
• sesgo de planeación —La tendencia a subestimar con optimismo la cantidad de tiempo requerido para completar una tarea.
• carta del proyecto — Una “fuente de información única y consolidada” (Richter 2014) para la iniciación y planeación de proyectos. Describe sus conocimientos actuales sobre el proyecto e incluye información como los nombres de todas las partes interesadas, una declaración de las necesidades de su organización, el historial previo al proyecto, el propósito del proyecto, los entregables y los roles y responsabilidades. Una carta de proyecto también se llama a veces una declaración general del proyecto. A veces es útil pensar en la carta del proyecto como un contrato entre el equipo del proyecto y los patrocinadores del proyecto.
• iniciación del proyecto —La fase inicial en la que se sientan las bases para todo el proyecto.
• declaración general del proyecto — Ver carta del proyecto.
• alcance del proyecto —Todo el trabajo “que hay que hacer para brindar el producto o servicio que tu proyecto está entregando” (Martínez n.d.).
• matriz de asignación de responsabilidad (RAM): un tipo de estructura de desglose organizacional en forma de cuadrícula que normalmente enumera las tareas del proyecto en la primera columna, y las partes interesadas en la fila superior, con tareas asignadas a las diversas partes interesadas. Puedes usarlo para determinar si tienes suficientes recursos para un proyecto, y para registrar quién es el responsable de qué. Ver también gráfico RACI.
• Gráfico RACI —Un tipo de matriz de asignación de responsabilidad (RAM). También conocido como gráfico de responsabilidad lineal. El nombre “RACI” es un acrónimo de “responsable, responsable, consultar e informar”.
• stakeholders —Las personas que se verán afectadas o que pueden afectar un proyecto.
• fluencia de alcance: cambios incontrolados en un proyecto que ocurren sin cambios autorizados correspondientes en el presupuesto y el cronograma.
• sentencia scope —Un documento que define el alcance (o requisitos) del proyecto.
• estructura de desglose del trabajo (EDT): una descripción de las tareas asociadas con los entregables del proyecto, a menudo en forma de diagrama de árbol. Una estructura de desglose del trabajo “muestra la relación de cada tarea con las demás tareas, con el conjunto y el producto final (meta u objetivo). Muestra la asignación de responsabilidad, e identifica los recursos requeridos y el tiempo disponible en cada etapa para el monitoreo y gestión de proyectos” (Diccionario de Negocios n.d.).
• paquete de trabajo — Un “grupo de tareas relacionadas dentro de un proyecto. Debido a que ellos mismos parecen proyectos, a menudo se les considera como subproyectos dentro de un proyecto más grande. Los paquetes de trabajo son la unidad de trabajo más pequeña en la que se puede desglosar un proyecto al crear su Estructura de Desglose del Trabajo (EDT)” (Wrike n.d.).

~Referencias

Beedle, Mike, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, Jim Highsmith, Andrew Hunt, et al. n.d. “Principios detrás del Manifiesto Ágil”. AgileFesto. Accedido el 16 de junio de 2018. http://agilemanifesto.org/principles.html.

Bigelow, Brad. 2012. “Ámbito: dominar la restricción difusa”. Instituto de Gestión de Proyectos. Accedido junio 16, 2018. www.PMI.org/~/media/miembros/R... ntBigElow.ashx.

Bradley, Jeremy. n.d. “¿Qué es una estructura de desglose organizacional (OBS)?” Crón. Accedido el 16 de junio de 2018. http://smallbusiness.chron.com/organ...obs-72523.html.

Diccionario de Negocios. n.d. “Externalidades”. BusinessDictionary. Accedido el 16 de junio de 2018. http://www.businessdictionary.com/de...rnalities.html.

—. n.d. “Estructura de desglose del trabajo (EDT).” BusinessDictionary. Accedido el 16 de junio de 2018. http://www.businessdictionary.com/de...cture-WBS.html.

Carlson, Nicholas. 2013. “El nuevo producto móvil de Facebook es un gran fracaso porque fue construido por usuarios de iPhone”. Business Insider, 13 de mayo. http://www.businessinsider.com/faceb... -segundo-2013-5.

Doglione, Cara. 2018. “Entender la Matriz de Asignación de Responsabilidad (Matriz RACI) PM. 25 de enero. http://project-management.com/unders...x-raci-matrix/.

Feldsher, Roni. 2016. “Qué incluir en una declaración de alcance de proyecto”. Clarizen. 9 de julio. https://www.clarizen.com/what-to-inc...ope-statement/.

Franzen, Carl. 2014. “La historia del Walkman: 35 años de reproductores de música icónicos”. The Verge, 1 de julio. http://www.theverge.com/2014/7/1/586... -walkman-at-35.

Friedman, Thomas L. 2005. El mundo es plano: una breve historia del siglo XXI. Nueva York: Farrar, Straus y Giroux. https://books.google.com/books?id=-m...l%20educated%2.

Harvard Business School Publishing Corporation. 2006. La gestión de proyectos grandes y pequeños: las habilidades fundamentales para cumplir con el presupuesto y a tiempo. Boston: Harvard Business School Publishing Corporation.

Heifetz, Ronald A., Marty Linsky, y Alexander Grashow. 2009. La práctica del liderazgo adaptativo: herramientas y tácticas para cambiar su organización y el mundo. Boston: Harvard Business Press.

Hill, Andrew. 2016. Cómo evitar el promedio de ideas: Deja pasar solo las mejores ideas. 4 de enero. http://andrewxhill.com/blog/2016/01/...dea-averaging/.

Investopedia. n.d. “entregables”. Investopedia. Accedido el 15 de junio de 2018. https://www.investopedia.com/terms/d/deliverables.asp.

—. n.d. “externalidad”. Investopedia. Accedido el 15 de junio de 2018. https://www.investopedia.com/terms/e/externality.asp.

Jordan, Andy. 2012. “Los 9 secretos de la iniciación exitosa de proyectos”. ProjectManagement.com. Marzo. http://www.projectmanagement.com/pdf...initiation.pdf.

Kanter, James. 2009. “En Finlandia, el Renacimiento Nuclear se encuentra en problemas”. The New York Times, 28 de mayo. http://www.nytimes.com/2009/05/29/bu...nuke.html? _r=0.

Martinez, Michael. n.d. Alcance de la Gestión de Proyectos. Accedido el 16 de junio de 2018. https://www.project-management-skill...ent-scope.html.

McCracken, Harry. 2013. “Este año tonto: los 47 momentos más tontos de la tecnología 2013”. Tiempo, 31 de diciembre. http://techland.time.com/2013/12/31/... -en-tech-2013/.

Meißner, M., y L. Bendición. 2006. “Definición de una Metodología Adaptativa de Desarrollo de Productos Actas de la Conferencia Internacional de Diseño DESIGN 2006. Dubrovnik, Croacia: Sociedad de Diseño. 69-78.

Mucha, Michael, entrevista de Ann Shaffer. 2017. Problemas Técnicos y Adaptativos (11 de diciembre).

OptiSol. n.d. “¿Qué es la fluencia de alcance en el desarrollo ágil?” Optisol Negocios. Accedido el 17 de junio de 2018. https://www.optisolbusiness.com/insi...le-development.

Porter, Michael E., y Thomas Lee, MD Lee. 2013. “La estrategia que arreglará el cuidado de la salud”. Harvard Business Review, octubre. https://hbr.org/2013/10/the-strategy...ix-health-care.

Portny, Stanley E. n.d. “Qué incluir en una declaración del alcance del proyecto”. Dummies. Accedido el 15 de junio de 2018. http://www.dummies.com/careers/proje...ope-statement/.

Richter, Linda. 2014. “¿Qué es una Carta de Proyectos?” Bright Hub Gestión de Proyectos. 24 de octubre. http://www.brighthubpm.com/project-p...oject-charter/.

Rife, Mat. 2005. “La reconstrucción del Pentágono es un estudio moderno en el método de construcción de diseño y construcción”. Austin Business Journal, 13 de noviembre. http://www.bizjournals.com/austin/st...14/focus3.html.

Tate, Ryan. 2013. “Facebook Home Será un “Gran Flop” Hasta Que No Lo Es”. Cableado, 14 de mayo. http://www.wired.com/2013/05/facebook-home-criticism/.

TechTarget. n.d. “caso de negocios”. Qué es. Accedido el 16 de junio de 2018. http://whatis.techtarget.com/definition/business-case.

Agencia de Protección Ambiental de Estados Unidos. n.d. Diseño para las evaluaciones del ciclo de vida del medio ambiente. Accedido el 16 de junio de 2018. https://www.epa.gov/saferchoice/desi...le-assessments.

Wrike. n.d. “Guía de Gestión de Proyectos/¿Qué es un Paquete de Trabajo en Gestión de Proyectos?” Wrike. Accedido el 16 de junio de 2018. https://www.wrike.com/project-manage...ct-management/.