Anteriormente hablamos de los supuestos del proyecto, en esta ocasión miramos hacia las restricciones. Ambos temas afectan o podrían afectar directamente el desempeño y planificación del proyecto, así como su cumplimiento. Las restricciones son, en sí, la camisa de fuerza que nos limita.

Según el PMBOK, las restricciones (constrains) son “el estado, calidad o sentido de estar restringido a un determinado curso de acción o inacción. Una restricción o limitación aplicable, sea interna o externa al proyecto, que afectará el desempeño del proyecto o de un proceso“.

Estoy seguro que habrán visto más de una vez el triángulo de la “triple restricción”. Los limitantes básico de los proyectos dados por el tiempo, los recursos y el alcance, corresponden al día a día de las negociaciones con clientes, proveedores, equipo y stakeholders.

Por lo anterior, es muy importante y mandatorio dejar las reglas e identificar las restricciones desde el inicio del proyecto. Mejor dicho, desde la conceptualización o propuesta comercial, si vale el término. Así como los supuestos, las restricciones tienen un alto impacto en temas como: costos, cronograma, fechas de entrega, etc.

Las restricciones vendrán dadas en temas como:

• Fecha esperada de entrega del proyecto
• Presupuesto máximo asignado al proyecto
• Cantidad de recursos humanos y técnicos disponibles
• Requerimientos mínimos necesarios y esperados (Alcance)

Con los puntos anteriores se podrán negociar escenarios como:

• Proyecto realizado por etapas (versionamiento)
• Priorización de requerimientos
• Negociación para obtener disponibilidad de recurso humano clave

Como bien dijo alguna vez un profesor : “No te adelantes a decirle al cliente que no se puede, en cambio, negocia con las restricciones“.

• “La fecha es lo importante”, entonces prioricemos los requerimientos y quizá tendremos que revisar el presupuesto.
• “El proyecto debe estar totalmente completo”, entonces revisemos la fecha para lograr cumplirlo.
• “El presupuesto es inamovible”, entonces no toquemos los recursos pero seleccionemos los requerimientos principales.

En resumen, es importante desde el inicio saber exactamente cuáles son las restricciones que limitan el proyecto, y de esas, conocer cuál es la más importante para saber por donde poder negociar… Y si para el cliente “todo es importante”, entonces, le cuentan el ejemplo del globo.

Quizá en alguna ocasión le molestó un comportamiento inapropiado de un miembro de su equipo que podría afectar la relación con el resto. Tal vez una llegada tarde a la reunión de seguimiento, o la constante interrupción mientras otro miembro expone sus puntos de vista. Son algunos de los ejemplo de escenarios que podrían pasar cuando las reglas no están claras.

En inglés se denominan Ground Rules. El PMBOK las define como:

Una lista de comportamientos aceptables e inaceptables adoptados por el equipo de proyecto para mejorar la relación de trabajo, efectividad y la comunicación”

El mismo PMBOK, al detallar las técnicas utilizadas durante el proceso de “Desarrollo de equipos de Proyecto” describe que las reglas de juego (o ground rules) deben ser expuestas, compartidas y aceptadas por el equipo.

El proceso de discutir las reglas de juego permite a los miembros descubrir que valores son importantes para cada uno” p.214

Lo anterior deja de lado aspectos subjetivos o supuestos, dejando la película clara a todos los miembros sobre cómo debe comportarse, y cómo no hacerlo.

A continuación se comparten algunos ejemplos como referencia. Seguro que luego de dejar claro estos puntos, algunas cosas podrían mejorar en su próximo proyecto.

• Ejemplo de Reglas para reuniones desde PennState
• Ejemplo de Reglas de Juego desde Michigan State University

No le ha pasado que cuando está realizando el Plan de Proyecto o la Propuesta Comercial, automáticamente como por arte de magia, se asumen algunos puntos del proyecto como hechos verdaderos. Esos son justamente los supuestos. Pero, ¿qué sucede cuando esas suposiciones no son verdad?

Usando como referencia el PMBOK sobre los supuestos, dice por definición que: “son factores, que para propósitos de planificación, son consideramos como verdad, reales o como ciertos sin pruebas que lo demuestren. Los supuestos afectan todos los aspectos de la planificación del proyecto, y son parte de la continua elaboración el proyecto. El equipo de proyecto frecuentemente identifica, documenta y valida los supuestos como parte del proceso de planificación. Los supuestos usualmente involucran un grado de riesgo”.

Imaginemos por un momento que la propuesta comercial ha sido aprobada por el cliente, y habíamos asumido sin documentarlo, que la solución o proyecto era para ser implementado en el perímetro urbano. O más aún, que el cliente dispondrá de un equipo técnico capacitado en la tecnología en la cual se desarrollará la solución. O tal vez que el piloto se realizará en una sola locación. Todo lo anterior, a pesar de que parezcan ejemplos obvios podrían afectar radicalmente el tiempo, el alcance, el costo, y por ende, dejar poco margen de utilidad en el caso de que la propuesta comercial haya sido aprobada.

Entonces, ¿es importante documentar los supuestos? La respuesta contundente es: Si. Y no solo documentar, sino compartirlas con el cliente y el equipo de proyecto. Además, se debería tener un control de cada uno de los puntos identificados. Si durante el desarrollo del proyecto, se confirma que un supuesto no es cierto, entonces lo más probable es que se tendrá que documentar con un riesgo y establecer el respectivo plan de mitigación.

Los supuesto se deberían documentar desde el inicio mismo de la conceptualización del proyecto, así como los riesgos, los requerimientos y las restricciones. Así que una tablita de MS Excel no estará demás tener a mano para un mejor control y seguimiento.

Tomados del artículo ¿Project Management? Si, pero con cabeza.

Es importante transmitir que cada opinión será escuchada, tenida en cuenta y analizada… Si no sabemos admitir que una idea es mejor que la nuestra o que es el momento de dar el cambio, nunca seremos un buen project manager.”

No presiones a quienes están desarrollando, hazles comprender que cada componente separado ha de estar finalizado el día X, ni antes ni después. Si … quieren irse a tomar un café de 3 horas… permítelo; mientras cumplan el objetivo no hay ningún problema…”

Aunque estés encargado de gestionar el proyecto, de asignar los informes de error a quien corresponda y de dialogar para mantener la unidad, no estás por encima de ninguna persona de tu equipo. Si tienes que programar, programa. Si tienes que reiniciar un servidor, reinícialo. Si tienes que tomarte una cerveza con el equipo, te la tomas. Es muy importante que todo el equipo tenga igualdad absoluta.”

En caso de necesitar una funcionalidad e ir desesperado a buscar en la web la última super-mega-killer-library, piensa cuales son los requisitos. Seguramente con un pequeño código ya obtengas lo suficiente para lo que quieres añadir”

Ver artículo completo en el siguiente enlace.

Tratando de ser objetivos podríamos establecer que la negación de una firma se deba a:

Por falta de Autoridad…

1. El Cliente (ya sea el jefe de proyecto, responsable, etc.) no tiene la autoridad formal y documentada otorgada por el superior
2. El Cliente, al no tener la autoridad o no conocer su rango de acción, redirecciona la responsabilidad de aprobación a un nivel superior
3. El Cliente, para asegurar una aprobación escrita, requiere del compromiso y aprobación de todos los involucrados dentro de su organización (esto implica mucho tiempo usualmente)

Por desconocimiento…

1. El Cliente no conoce lo que debe aprobar ( no sabe qué entregables son y qué aspectos debe cubrir)
2. El Cliente no entiende qué implica la aprobación y sus consecuencias en las siguientes etapas del proyecto
3. El Cliente no tiene una idea clara del Alcance del proyecto y la metodología a seguir
4. El Cliente desconoce del impacto por la falta de aprobación

Debido a todo lo anterior se podría resumir algunos temas a tener en cuenta:

• La demora en aprobaciones es un riesgo con altísima probabilidad, y con impacto en tiempos de entrega
• El Cliente requiere ser capacitado en sus responsabilidades hacia el proyecto y en la metodología a seguir
• Se debe dejar en claro que es necesaria una aprobación durante las etapas de desarrollo para asegurarnos todos los involucrados que se está realizando un proyecto acorde a lo establecido, y que existe el compromiso y acuerdo entre todas las partes.

Estimado Sr. Cliente: Entiendo que tenga temor a firmar un papel. Pero quizá es por desconocimiento. Para eso estamos, para explicarle y despejar cualquier duda. Pero también entienda que como proveedores si Ud. no aprueba el “plano de la casa” y la construimos sin la seguridad de que eso es lo que quiere, el impacto de esa decisión después podría ser muy grave para todos.

En mi ciudad, Guayaquil, a diferencia de muchas otras ciudades del mundo, los taxis no utilizan taxímetro. Los taxistas negocian un precio antes de proveer su servicio. La semana pasada, al tomar un taxi negociamos un precio fijo, las condiciones cambiaron y algunos riesgos se presentaron. ¿Quién se perjudicó?

Tomé el taxi y le di mi destino. Necesitaba ir del punto A al B, como siempre lo hago. Era un viaje de aproximadamente unos 15 min. y que usualmente cobran X cantidad de dólares. Pactamos el precio fijo y comenzó el viaje. A los pocos minutos se inició una torrencial lluvia, el tráfico se complicó y se tuvo que analizar caminos alternativos que aumentaron la distancia y el tiempo del viaje. Esto afectó el servicio, ya que la situación de estrés y la potencial pérdida de dinero del taxista generó un ambiente de malestar. Al llegar a mi destino, el viaje había tomado 1 hora. El precio había sido pactado en X, pero como cliente estaba consciente que las condiciones habían cambiado. Volvimos a negociar un precio al final del camino y terminé pagando Y.”

Con el taxímetro (precio variable), seguramente el precio habría sido más razonable para ambas partes. Como cliente tal vez me hubiese estresado al darme cuenta que en el display el precio aumentaba y se salía de mi presupuesto para el viaje, pero hubiese podido pagar el servicio hasta donde me alcance. Como proveedor, el taxista hubiese asumido menos riesgo y por ende, el estrés no habría afectado el servicio.

Sin el taxímetro (precio fijo), como cliente habría tenido argumentos para no pagar más de lo pactado. Realmente no me hubiese afectado ni el tráfico ni lluvia, pero corría el riesgo de que el taxista me deje botado en media calle. En cambio, el taxista se arriesgaba con un precio fijo, a no poder renegociar, y por ende, asumir el impacto que habían provocado las condiciones cambiantes de lo originalmente pactado.

En resumen, para tranquilidad de ambas partes, me quedo con el uso del taxímetro!

El título de este post dice “protégete”, pero también debería decir “protege a tu proyecto y equipo”. El PM debe estar consciente de que en cualquier momento un mail, una conversación informal, un requerimiento solicitado por messenger, etc. podría ser una puerta abierta para afectar leve o gravemente el proyecto. Aún existiendo procesos claros para gestión de cambios, o levantamiento de requerimientos, la experiencia nos indica que se pueden filtrar aspecto que afecten el Alcance del Proyecto, o peor aún, generen insatisfacción en el cliente y/o usuario. Por eso deberíamos tener claro que:
Se debería documentar todo, especialmente…

• Requerimientos
• Cambios
• Novedades
• Definiciones
• Issues
• Riesgos
• Especificaciones
• Y todo lo que pueda cambiar o afectar lo originalmente planteado ya sea del producto final o del proyecto

Se debería documentar en…

Documentos físicos: cartas, memos, diagramas de flujo, bocetos, entre otros.
Documentos digitales: emails, archivos aprobados, todo documento involucrado en el proceso de gestión del proyecto y de desarrollo del producto

Con especial atención en…

Aprobaciones internas (dentro del equipo de proyecto): asignación de recursos, presupuestos, especificaciones, diseños de solución, etc.
Aprobaciones externas (hacia el cliente): solicitudes de cambio, aprobación de entregables, aprobación de fechas, aprobación de costos

Recuerda…

“Lo no escrito, no dicho”

La próxima vez que el cliente lo pida verbalmente, tómate el tiempo de documentarlo, hacerlo aprobar y guárdalo. No sabes en qué momento eso te podrá salvar de un desviación en tu proyecto.

___________________

Otros tips por si te sirven:

• Capacita a tu jefe !
• Escala la situación !

PM World Today también presenta en su edición de febrero otros artículos especializados sobre Dirección de Proyectos, tip, técnicas y reportajes de más de 10 países sobre temas relacionados a Project Management.

El Jefe que es justamente a quien nosotros escalamos, consultamos o validamos muchas de las decisiones que debemos tomar , o en su defecto, es quien realiza los negocios o maneja el tema comercial, es justamente quien debe estar al tanto de cómo se gestionan y desarrollan los proyectos.

¿Tu jefe está al tanto de los pasos necesarios y oportunos que se deben hacer para poder dar una fecha real de finalización del proyecto?
Usualmente no. Ellos simplemente quieren una fecha, y obviamente una fecha cercana.

¿Tu jefe está al tanto de lo que se debe hacer y las implicaciones que abarca establecer un precio fijo a un proyecto en una etapa inicial?
Usualmente no. Ellos quieren un precio rápido y que los costos planificados no aumenten.

¿Tu jefe está consciente de que existe factores internos y externos que podrán afectar el margen de utilidad del proyecto, o demorar su entrega, o afectar la percepción del cliente?
Usualmente no. Ellos no quieren sorpresas y pero escuchar la palabra “riesgo”.

¿Tu jefe tiene claro que el proyecto se desarrolla gracias a un equipo integrado y comprometido, y que de este equipo depende el correcto resultado del proyecto?
Usualmente si, pero piensa que todos deben hacer su trabajo.

¿Y la motivación? Seguramente no conocen esa palabra!

Con todo lo anterior, no sería una locura pensar que es necesario que tu jefe se capacite tanto como tu en la gestión de proyectos. De cualquier forma, si tu trabajo y desempeño depende de la óptima gestión de los proyectos… el desempeño de tu jefe depende del tuyo y el de tu equipo. A la final a todos les interesará estar bien enterados del tema!

Suerte con tu jefe!

______________________

Otro tip por si te sirve:

• Escala la situación !

• Existe un cambio que podría afectar el cronograma o el presupuesto aprobado… Escálalo al comité administrativo
• Una nueva característica podría mejorar el producto o proyecto final… Escálalo al sponsor
• El cliente está presionando por comprimir las fechas del cronograma… Escálalo a tu jefe
• Se requiere adquirir algo necesario pero fuera del presupuesto… Escálalo al comité administrativo
• Un usuario clave no está de acuerdo con el proyecto, aunque el sponsor si… Escálalo al sponsor
• El cliente se queja por tu gestión… Escálalo a tu superior

Conoce tu rango de acción, límites y autoridad. Comprende perfectamente el alcance del proyecto, tu presupuesto y recursos.
Para todo aquello que esté fuera, escálalo hacia arriba. Si tomas decisiones sin autorización previa y por escrito, deberás enfrentar algunas consecuencias.