Blockchain, la tecnología que sirve de soporte a las criptomonedas, ya está empezando a cambiar la forma de hacer negocios y sin duda cambiará la forma de gestionar proyectos. Imagino que las primeras aplicaciones de Blockchain que veremos en el ámbito del project management no se limitarán a pagar a los subcontratistas con dinero virtual. Es más probable que las herramientas Project Management Information Systems (PMIS) comiencen usando Blockchain para programar lógica de negocio dentro de las transacciones, funcionalidad que se conoce como smart contracts. La lógica transaccional más simple consiste en guardar información.

En mi opinión, cabe imaginar principalmente tres casos de uso de los smart contracts aplicables al project management. A mi modo de ver, las herramientas PMIS usarán los smart contracts de Blockchain para:

  • Automatizar transacciones relativas a cláusulas contractuales con contratistas, por ejemplo: pagos ligados a la aceptación de entregables o al cumplimiento de hitos.
  • Registrar eventos significativos de la gestión del proyecto, por ejemplo: aprobación/cierre del proyecto o fase, asignación/desasignación de miembros del equipo, aprobaciones de horas y gastos, registrar el progreso o la terminación de actividades o tareas, registrar estados en el flujo de gestión de los cambios, registrar replanificaciones, aprobaciones de compras o subcontrataciones, etc.
  • Registrar el estado del proyecto, o lo que es lo mismo: grabar los informes de seguimiento.

Creo que este último punto es el que tiene más probabilidades de implantarse en el corto plazo por varios motivos:

  • Las herramientas PMIS pueden realizar la implementación, con las APIs de software ya disponibles, de forma transparente a los usuarios (que no necesitan ser conscientes de que, por debajo, se está usando una plataforma Blockchain).
  • Las organizaciones tienen cada vez mayor interés en dotar a los proyectos de mecanismos ágiles de transparencia sobre el estado de los proyectos, evitando la burocracia de preparar documentos o mantener reuniones de seguimiento. Prefieren informar a los interesados en tiempo real, en línea, por internet.
  • Existe un alto grado de correlación entre el éxito de los proyectos y su monitorización efectiva. Todos los proyectos que fracasan gravemente, con retrasos o sobrecostes desproporcionados, adolecen de malas prácticas a la hora de realizar los seguimientos. Por contra, en los proyectos que terminan con éxito, suele haber mucho rigor en los seguimientos periódicos: En cada reunión de seguimiento se miden desviaciones, se calculan pronósticos, se compara el desempeño contra las líneas base y se toman acciones correctoras para cumplir los objetivos de gestión de tiempo, coste, alcance, calidad, etc. Medir y ajustar regularmente es clave para terminar el proyecto en plazo y en coste: Si hoy tenemos un sobrecoste de 10.000€, ¿cómo podremos ahorrar 10.000€ para terminar sin sobrecoste? Si hoy prevemos un retraso final de 3 semanas, ¿cómo podremos adelantar 3 semanas para terminar en plazo?

El estado de un proyecto a una fecha determinada (project status date), puede formalizarse con información pública (accesible por todos los interesados) y con información confidencial (accesible solo al equipo de gestión y a ciertos interesados clave):

  • El registro confidencial del estado del proyecto es difícil de generalizar, pues exige adaptaciones en la mayoría de los casos para cumplir las necesidades de cada organización ejecutora y de cada proyecto. En este registro confidencial suele incluirse el desempeño financiero (e.g.: gastos y compras aprobados, previstos e incurridos; reservas planificadas y aplicadas; margen del proyecto real y previsto a la fecha, facturas pendientes, emitidas y cobradas, etc.), desempeño de los miembros del equipo, lecciones aprendidas, registro de comunicaciones, incidentes, supuestos, riesgos, interesados, mediciones de control de calidad, etc.
  • El registro público del estado del proyecto, o lo que es lo mismo, el registro de propósito general de interés para cualquier stakeholder del proyecto, sí es fácil de generalizar si incluye la fase actual en la que se encuentra el proyecto, el desempeño de alto nivel, el desempeño sobre las 3 líneas base (alcance, cronograma y coste) y las solicitudes de cambios. Estos 4 campos pueden representar, para una fecha determinada, el registro público del estado del proyecto.

Si nos centramos en este registro público, más susceptible de ser salvaguardado en transacciones de Blockchain, la historia de cualquier proyecto podría resumirse a través de los diferentes registros de estado en las sucesivas fechas de seguimiento.

Pensemos ahora en las 4 situaciones posibles para un registro de estado del proyecto:

  • Registro Privado: El estado del proyecto no se ha publicado en Blockchain.
  • Registro Público: El project manager ha publicado el estado en Blockchain.
  • Registro Verificado: Al menos un stakeholder ha verificado que la información grabada en Blockchain coincide con la que ofrece la herramienta PMIS.
  • Registro Inválido: Al menos un stakeholder ha comprobado que la información grabada en Blockchain difiere de la que ofrece la herramienta PMIS.

Veamos un ejemplo:

  • Los usuarios con acceso a los project status reports en la herramienta PMIS ven que los registros de los días 17 y 24 de agosto no se han publicado, el del día 31 se ha publicado pero nadie lo ha verificado, los días 7 y 21 de septiembre sí están verificados, pero el del día 14 ha sido alterado en la herramienta PMIS, razón por la cual ahora difiere del registro publicado en Blockchain.

  • En cualquier momento, el project manager puede publicar los registros de los días 17 y 24 de agosto. También puede “despublicar” el registro del 14 de septiembre para volver a publicarlo después (la herramienta PMIS invocará una nueva transacción Blockchain, que grabará los datos en un nuevo bloque).

Las posibles transiciones pueden verse representadas en el siguiente diagrama de estados:

La operación para verificar un registro debe realizarse desde la herramienta PMIS de forma transparente para el stakeholder. La herramienta puede reconstruir el fichero a partir de su información, y comparar el resultado de la función hash con el guardado en la transacción de Blockchain. Si el stakeholder supiera el código de la transacción de Blockchain, también podría conseguir el código hash del fichero usando cualquiera de las herramientas públicas que permiten explorar la cadena de bloques.

Así pues, ya sabemos cómo guardar en Blockchain los diferentes estados de un proyecto. El estado agregado de un programa o portafolio podría componerse a partir de los estados de sus proyectos en fecha published status date de cada proyecto. También puede agregarse la información a nivel de un departamento (Business Unit) y agregando los departamentos de la organización, tendríamos la “foto” del estado de la gestión de proyectos organizacional:

En una organización “confiable” cabe esperar ciertas mejoras en la gestión de los proyectos:

  • Los interesados que participen en proyectos “confiables” tendrán mayores expectativas sobre los seguimientos, se involucrarán mejor y contribuirán proactivamente a su conclusión exitosa.
  • Los project managers que dirijan projectos “confiables” aplicarán mejores prácticas en los seguimientos porque tienen “público” pendiente de la veracidad de la información publicada.

Interesados y project managers saben que hay un mecanismo para salvaguardar los registros en Blockchain, pero la herramienta PMIS debe ocultar los detalles técnicos. El uso de Blockchain también abre la posibilidad de interoperabilidad entre diferentes herramientas PMIS: sólo necesitan consensuar el formato y la estructura de los campos.

Notas de Implementación

  • Según el uso, existen 3 tipos de plataformas Blockchain: sólo para criptomonedas (e.g. Bitcoin), para criptomonedas y lógica de negocio (e.g. Ethereum) y solo para lógica de negocio (e.g. Hyperledger). Aunque Bitcoin ya permite incluir lógica de negocio en las transacciones, se desaconseja para guardar ficheros debido al alto coste de las comisiones. Por otro lado, si se quiere acelerar y facilitar la adopción transparente, sin exigir conocimientos previos y ocultando los detalles técnicos, se desaconsejan las implementaciones de Hyperledger por la complejidad de gestionar los permisos de los participantes (algunos de los cuales deberían ser validating peers).
  • Por lo que se refiere a la privacidad, existen 3 categorías de plataformas Blockchain: plataformas públicas (e.g. Bitcoin, Ethereum), privadas y autorizadas (permissioned). Para facilitar la adopción, haciendo posible que los participantes puedan no ser conscientes de la tecnología subyacente (sin que deban instalarse en su ordenador máquinas virtuales, por ejemplo) se recomienda el uso de Ethereum. Se aconseja que la herramienta PMIS maneje internamente los códigos de transacción, ofreciendo la posibilidad de que los usuarios finales puedan copiar dichos códigos.

  • Para que las comisiones de Ethereum sean bajas (del orden de céntimos de USD), se aconseja usar IPFS como plataforma de almacenamiento, de manera que en la transacción de Ethereum solo sea necesario guardar el código hash del fichero.

  • Cualquier herramienta PMIS podría generar el fichero del estado del proyecto y guardarlo en IPFS. El proveedor de la herramienta PMIS debería tener una cuenta en Ethereum para pagar las comisiones de las transacciones. Las transacciones no supondrían transferencia de ethers, solo guardar el código hash de IPFS. Los usuarios de pago deberían provisionar un saldo suficiente (un saldo de 0,05 ETH, unos 15 USD, sería suficiente para costear unas 1.000 transacciones). Obsérvese en el diagrama de estados que la transacción Blockchain solo ocurre cuando el project manager publica el registro:

Artículo relacionado: Organizaciones Proyectizadas Confiables con PMPeople

Mi presentación en la reunión de socios de PMI Madrid en abril 2019:

Aquí puede ver un vídeo resumiendo nuestra implementación en PMPeople

Pulse aquí para leer este artículo en inglés.

Compartir: