TEMA 5. DISEÑO Y DESARROLLO DE PROYECTOS DIGITALES DE SALUD

1. FUNDAMENTOS DE GESTIÓN DE PROYECTOS

Un proyecto es un conjunto único de actividades interrelacionadas diseñadas para producir un conjunto de resultados y alcanzar un objetivo definido, todo ello con unas restricciones de tiempo, coste económico y calidad. Todo esto se resume con el llamado objetivo 3D o triángulo del proyecto: cumplir las especificaciones, terminar a tiempo y estar dentro del presupuesto.

Comprender la definición de un proyecto es un primer paso importante para entender la gestión de proyectos. Un proyecto es una actividad temporal que se va elaborando progresivamente a medida que se avanza en el ciclo de vida y produce un producto, servicio o resultado único. Debido a estas características, un proyecto es diferente de un proceso.

Debido a que es un esfuerzo temporal, un proyecto tiene un inicio y un fin definidos. Un proyecto comienza cuando se identifica una necesidad y termina cuando se alcanzan los objetivos específicos y son formalmente aceptados por el promotor. Un proyecto también puede finalizar si se toma la decisión de terminarlo antes de alcanzar el resultado final. La naturaleza temporal de un proyecto no significa que todos los proyectos duren solo un corto período de tiempo. Los proyectos pueden durar semanas o años, pero independientemente de la duración, cada proyecto pasa por todas las fases del ciclo de vida del proyecto.

1.1. Ciclo de vida del proyecto

A pesar de que los proyectos son muy diferentes, todos avanzan a través de un ciclo de vida básico común, desde la iniciación hasta el cierre, pasando por las fases de planificación/preparación e implementación. Pensar en las fases en un ciclo de vida del proyecto es útil tanto para ver el panorama general como para planificar y gestionar cada fase. Pero sería un error pensar que tener una idea, conceptualizar la idea en un proyecto y completar con éxito el proyecto es un proceso lineal. Los proyectos generalmente no van exactamente según lo planeado, y los gestores tienen un papel crítico en monitorizar el progreso, identificar problemas o variaciones, modificar el plan y tomar medidas en consecuencia.

Aunque es útil planificar y gestionar el proyecto en fases, las fases no están separadas; más bien, tienden a superponerse y a menudo carecen de límites claros. Incluso cuando el equipo está utilizando un método de gestión de proyectos con pasos de aprobación formales, es posible que no haya un punto obvio donde puedan decir "la fase de iniciación está completa, ahora estamos comenzando la fase de planificación".

El ciclo de vida predictivo es un enfoque más tradicional en el que la mayor parte de la planificación se completa al principio, seguida de la ejecución de manera secuencial. La forma más común de este ciclo de vida es el enfoque de cascada (Waterfall), que analizamos posteriormente. Estos enfoques asumen que existen requisitos sólidos y un bajo riesgo. Hay un plan detallado que proporciona al equipo el conocimiento de qué entregar, cómo y cuándo. El valor empresarial se entrega al final del proyecto.

El ciclo de vida iterativo permite recibir retroalimentación sobre el trabajo incompleto, lo que permite modificaciones y mejoras. Este ciclo de vida utiliza prototipos o pruebas de concepto para mejorar el producto o el resultado. Cada versión iterativa permite recibir retroalimentación de las partes interesadas, que luego se incorpora en el siguiente ciclo. Las iteraciones ayudan a identificar y reducir la incertidumbre en el proyecto. Esto es beneficioso cuando el proyecto es altamente complejo, no hay consenso sobre el alcance o hay cambios frecuentes. Los ciclos de vida iterativos están optimizados para el aprendizaje, no para la velocidad de entrega, por lo que la duración tiende a ser más larga.

El ciclo de vida incremental proporciona funcionalidad completa que el cliente puede utilizar de inmediato, pero en entregables más pequeños. El equipo planifica la salida antes de comenzar cualquier trabajo y comienza el desarrollo del primer entregable de inmediato. Debido a la entrega rápida de productos incrementales, el equipo puede gestionar cambios en los requisitos o incluso en la visión original del alcance.

Esta imagen define perfectamente las diferencias entre el modelo iterativo y el incremental:

En el marco del desarrollo iterativo e incremental surge el concepto del producto mínimo viable (MVP) que es una de las mejores formas de validar las hipótesis. El MVP viene a ser la versión del producto que permite dar la vuelta entera al circuito de crear-medir-aprender, con un mínimo esfuerzo y en un mínimo tiempo. El Producto Mínimo Viable (MVP) es un producto muy básico, con las funcionalidades esenciales y que permite probar la reacción que tiene el público objetivo. Con su feedback, es posible reconstruir y mejorar el producto, para lanzar una nueva versión y realizar el mismo proceso. Este ciclo se repite varias veces para ir puliendo el producto.

La gestión de proyectos es importante para las organizaciones y equipos, pero para que sea efectiva, la metodología de gestión de proyectos debe coincidir con el tipo de equipo, proyecto, organización y objetivos. Elegir la metodología o marco adecuado para llevar a cabo un proyecto es importante porque define cómo el director de proyecto y el equipo realizarán el trabajo. Después de todo, no se puede usar un martillo para abrir un tornillo. De hecho, una de las razones fundamentales detrás de los fracasos en los proyectos se debe a la elección incorrecta de la metodología de gestión de proyectos.

Algunos proyectos son simples y predecibles, mientras que otros son complejos y arriesgados. Aplicar la misma cantidad de rigor en la gestión de proyectos, independientemente de la necesidad, puede resultar en un desperdicio de recursos. Para tomar una decisión informada para la empresa, el director de proyecto debe desarrollar el conocimiento y las habilidades necesarias para aplicar múltiples metodologías de gestión de proyectos y también debe elegir un enfoque que se encuentre en algún punto intermedio entre depender en exceso de una metodología y rechazar toda la gestión de proyectos.

1.2. Metodología

La mejor metodología es aquella que permite al director de proyecto y al equipo entregar una solución de manera que optimice el tiempo del equipo, oriente el trabajo hacia el logro de objetivos estratégicos con los mayores beneficios y el menor impacto negativo, y maximice la satisfacción del usuario final. Un enfoque pragmático, en lugar de dogmático, tiene sentido al elegir una metodología. Los equipos de proyecto también están aprendiendo a combinar diferentes estilos, descubriendo nuevos beneficios y logrando el éxito en la entrega de proyectos.

Las tres principales metodologías de gestión de proyectos son la gestión en cascada (waterfall), agile y las metodologías híbridas.

Modelo en cascada o Waterfall

El modelo Waterfall (cascada) hace referencia a una metodología que sigue la filosofía de "hacerlo una vez y hacerlo bien la primera vez". Esta estrategia bien conocida sigue un enfoque lineal y secuencial a lo largo de un único ciclo de vida largo con múltiples etapas. El progreso se desarrolla en una única dirección, descendiendo como una cascada.

El director de proyecto y las partes interesadas definen de manera extensa y detallada los requisitos y las expectativas desde el principio, antes de que comience cualquier trabajo. Una vez que las autoridades aprueban el alcance del proyecto y comienza la ejecución, se sigue una secuencia específica de fases, adhiriéndose a los requisitos definidos y siguiendo una dirección lineal. Se requieren solicitudes de cambios y nuevas aprobaciones para modificar el alcance, el cronograma o el presupuesto una vez que se aprueba el plan.

Cada etapa es independiente y se completa antes de que pueda comenzar la siguiente fase. El resultado de una fase actúa como entrada para la siguiente fase en un patrón secuencial. Como tal, una vez que una fase ha finalizado, no se vuelve a visitar. Las partes interesadas participan solo en los hitos de control y el tiempo y el presupuesto están fijos en Waterfall. En Waterfall, los procesos de gestión de proyectos están claramente definidos y mantener documentación completa y consistente es de suma importancia. Finalmente, debido a la planificación temprana y extensa, el director de proyecto desempeña un papel importante en Waterfall.

Entre sus ventajas encontramos las siguientes:

Waterfall es ampliamente conocido, directo y fácil de entender, implementar y utilizar. Invertir tiempo en las etapas iniciales de un proyecto garantiza que el diseño y los requisitos se identifiquen y documenten desde el principio, estableciendo expectativas desde el comienzo.
Las etapas son intuitivas y fáciles de comprender, independientemente de la experiencia previa. La estructura proporciona una clara diferenciación entre las etapas que ayuda a organizar y dividir el trabajo en partes.
Reunir y documentar los requisitos facilita que nuevos recursos se pongan al día y trabajen en el proyecto cuando sea necesario.
Los planes de proyectos anteriores se pueden copiar y aplicar a nuevos proyectos con ajustes menores.

Este proceso lógico y metódico funciona bien para las industrias de fabricación y construcción, ya que están creando productos físicos y siguen líneas de montaje lineales. Por ejemplo, cuando se está construyendo una maquina industrial o instalando un TAC en un hospital, ejecutar una serie de pasos bien pensados y cumplir plazos estrictos para entregar un proyecto completo que cumpla con todos los requisitos definidos es lo que se necesita.

Esta metodología tiene algunas desventajas evidentes. Por ejemplo, se asume que el director de proyecto y las partes interesadas tienen un profundo conocimiento de los requisitos y que estos serán identificados y analizados correctamente al comienzo del proyecto. Esta metodología sigue un proceso altamente estructurado y si se encuentra un error en los requisitos en algún momento o si es necesario realizar un cambio después de que una etapa esté completa, el proyecto debe reiniciarse desde el inicio de la última etapa (o incluso antes). Esta circunstancia potencialmente aumenta los riesgos y los costes, y puede retrasar el cronograma.

Otra crítica es que su principal objetivo es ayudar a los equipos internos a moverse de manera más eficiente en lugar de centrarse en el usuario final o el cliente. Las partes interesadas no tienen la oportunidad de proporcionar aportaciones durante el desarrollo, excepto cuando se alcanzan hitos, en las pruebas de aceptación del usuario o cuando se lanza el producto. Además, dejar la fase de pruebas para las etapas finales de un proyecto es arriesgado, ya que esto deja margen para que los problemas pasen desapercibidos hasta que el proyecto esté cerca de su finalización.

La metodología en cascada se asocia habitualmente a los diagramas de Gantt como este:

Metodología Agile

Agile es más una filosofía, ideología o enfoque basado en unos valores y principios específicos. El método de ejecución final depende del modelo que se elija, como Scrum, Lean, Kanban, etc. Cada uno de estos métodos ágiles aporta su propio conjunto de características, terminología y procesos. Al igual que Waterfall, los equipos de proyecto pasan por una serie de etapas de planificación, ejecución y evaluación. Sin embargo, Agile aplica un proceso de diseño y construcción colaborativo y evolutivo para el trabajo. Los miembros del equipo de proyecto ejecutan una serie de tareas y actividades que se conciben, realizan y adaptan según lo requiera la situación, en lugar de utilizar un proceso predefinido. Los equipos ágiles autodirigidos y multifuncionales trabajan en "sprints" de corta duración para completar un trabajo específico y prepararlo para su revisión. Cada uno de estos sprints se organiza en unidades de trabajo pequeñas y entregables a corto plazo (también conocidas como versiones). Analizaremos las metodologías ágiles en el siguiente apartado.

Metodología híbrida

El enfoque híbrido a veces se denomina "ágil híbrido", "ágil estructurado", "cascada iterativa", "Agilfall" o "WAgile". Sea cual sea el nombre, para algunos proyectos, ninguno de los dos enfoques en su forma pura tiene sentido y las organizaciones pueden beneficiarse al utilizar una combinación de ambos. La gestión de proyectos híbrida combina el estilo tradicional de cascada con los métodos ágiles más flexibles para crear un nuevo método de gestión de proyectos. Un modelo híbrido puede tener sentido si:

La organización está haciendo la transición a una nueva metodología y ciertas prácticas seleccionadas pueden implementarse gradualmente en lugar de todas de una sola vez.
Diferentes equipos que participan en el mismo proyecto desean utilizar diferentes metodologías.
La regulación o los requisitos contractuales pueden requerir un enfoque de gestión de proyectos más predecible para alguna parte del proyecto, pero el equipo de proyecto puede llevar a cabo una parte del trabajo de desarrollo utilizando Agile.

Existen muchas formas de seleccionar prácticas "a la carta" y diseñar e implementar una metodología híbrida. Una disposición común es aquella en la que el director de proyecto utiliza métodos Waterfall para crear una hoja de ruta de alto nivel del proyecto y luego emplea técnicas ágiles para desarrollar, refinar y lanzar componentes y subcomponentes del producto. Este ejemplo sigue un proceso con el siguiente formato:

Recopilar y documentar todos los requisitos.
Obtener la aprobación del diseño general.
Realizar iteraciones de desarrollo (sprints):

Diseño.
Desarrollo.
Pruebas.
Recopilar retroalimentación sobre lo que se ha producido hasta el momento (identificar cambios que se ajusten a los requisitos definidos según las prioridades).
Implementar cambios basados en esa retroalimentación y desarrollar, probar y solicitar más opiniones.

Implementar en producción una vez que las partes interesadas estén satisfechas con el producto.

La ventaja de un enfoque híbrido, como el descrito anteriormente, es que el director de proyecto y el equipo pueden definir el entregable y comprender las tareas de alto nivel y sus dependencias desde el principio, utilizando una estructura de desglose del trabajo estructurada. Luego, el equipo utiliza Agile para acelerar el desarrollo y la entrega del producto final mediante iteraciones. El enfoque híbrido tiene el potencial de mejorar la calidad del producto y reducir el tiempo de desarrollo.

Un enfoque híbrido puede hacer que la planificación y la estimación del proyecto sean más precisas al proporcionar la capacidad de reaccionar a los cambios según las demandas. Y una vez que el equipo haya pasado la etapa inicial de planificación, el método híbrido ofrece una mayor flexibilidad en comparación con el método Waterfall puro. Al tomar la fase inicial de planificación de Waterfall, el método híbrido aborda una de las principales quejas sobre Agile: la falta de predictibilidad.

Entre los inconvenientes del modelo híbrido, la implementación de un enfoque de este tipo requiere que el equipo y las partes interesadas tengan experiencia y conocimientos tanto en Waterfall como en Agile (lo cual no es necesariamente común).

Otra desventaja es que el equipo no se compromete completamente con ninguna de las metodologías y hay una abrumadora cantidad de combinaciones para elegir. Las organizaciones pueden estar manteniendo la mentalidad tradicional que obstaculiza el desarrollo ágil. El liderazgo del proyecto tendrá que hacer compromisos y equilibrar el control y la flexibilidad. Por ejemplo, desde el punto de vista de Waterfall, el equipo renuncia a un nivel de certeza para obtener la flexibilidad de Agile. Inversamente, los desarrolladores ágiles pierden cierta libertad y se ven más limitados, pero en general, el proyecto logra un mejor control del presupuesto, los recursos y el cronograma.

2. METODOLOGÍAS ÁGILES: SCRUM Y KANBAN

2.1. Filosofía Agile

Los valores ágiles que se definen en el manifiesto agile son 4 y son los pilares sobre los cuales se apoya la cultura Agile que define una forma de pensar y de hacer las cosas. Todos ellos nos sirven como guía para que nuestras acciones y decisiones estén orientadas hacia el cumplimiento de los mismos.

Los valores ágiles destacan la prioridad de determinados enfoques frente a otros. Ambos son válidos, pero se prefiere el primero (por ejemplo, es preferible centrarse en los individuos que en los procesos o herramientas). Los 4 valores ágiles son:

Individuos e interacciones sobre procesos y herramientas.
Software funcionando sobre documentación extensiva.
Colaboración con el cliente sobre negociación contractual
Respuesta ante el cambio sobre seguir un plan.

Los 12 principios ágiles, definidos en el manifiesto agile y que nos ayudan a poner en práctica los valores ágiles, son:

Nuestra mayor prioridad es satisfacer al cliente. ¿Y cómo? Pues mediante la entrega temprana y continua de software con valor.
Aceptamos que los requisitos cambien, incluso en etapas tardías del desarrollo. Los procesos ágiles aprovechan el cambio para proporcionar ventaja competitiva al cliente.
Entregamos software funcional frecuentemente, entre dos semanas y dos meses, con preferencia al periodo de tiempo más corto posible.
Los responsables de negocio y los desarrolladores tenemos que trabajar juntos de forma cotidiana durante todo el proyecto.
Los proyectos se desarrollan en torno a individuos motivados. Hay que darles el entorno y el apoyo que necesitan, y confiarles la ejecución del trabajo.
El método más eficiente y efectivo de comunicar información al equipo de desarrollo y entre sus miembros es siempre la conversación cara a cara. En los tiempos que corren es más complicado, pero en su defecto tenemos la videoconferencia.
El software funcionando es la medida principal de progreso.
Los procesos ágiles promueven el desarrollo sostenible. Los promotores, desarrolladores y usuarios debemos ser capaces de mantener un ritmo constante de forma indefinida.
La atención continua a la excelencia técnica y al buen diseño mejora la Agilidad.
La simplicidad, o el arte de maximizar la cantidad de trabajo no realizado, es esencial.
Las mejores arquitecturas, requisitos y diseños emergen de equipos autoorganizados.
A intervalos regulares, el equipo reflexiona sobre cómo ser más efectivo para a continuación ajustar y perfeccionar su comportamiento en consecuencia.

A Agile se le atribuye haber acelerado la innovación no solo en la industria del software sino también en varias otras, incluidas la fabricación o la logística. Independientemente del caso de uso específico, Agile ayuda a las empresas a pasar de un método en el que todo se planifica meticulosa y minuciosamente a uno que reconoce, planifica y acepta el cambio.

Un aspecto importante de la metodología Agile es el uso de métricas y datos para realizar un seguimiento del progreso y medir el éxito. Las métricas comunes incluyen la velocidad (la cantidad de trabajo completado en un sprint), el tiempo de entrega (el tiempo que lleva completar una tarea) y el tiempo de ciclo (el tiempo que lleva completar una tarea de principio a fin). También permite a las empresas detectar y responder rápidamente a los cambios en el entorno sanitario. Uno de los aspectos más importantes de Agile es que es una mentalidad, no sólo una metodología.

Ventajas:

Adaptabilidad: la gestión ágil permite a los equipos adaptarse a los cambios y cambiar cuando sea necesario, lo que es especialmente útil en industrias que cambian rápidamente.
Enfoque en el cliente: las metodologías ágiles dan mucha importancia a los comentarios y la colaboración del cliente, lo que puede ayudar a garantizar que el producto final sea exactamente lo que el cliente quiere y necesita.
Mejora continua: se anima a los equipos ágiles a reflexionar sobre sus procesos de forma regular y buscar formas de mejorar, lo que puede conducir a una mayor eficiencia y eficacia con el tiempo.
Entrega más rápida: los equipos ágiles trabajan con plazos cortos, lo que les permite entregar software funcional u otros entregables más rápido que los métodos tradicionales.
Comunicación mejorada: las metodologías ágiles ponen énfasis en la comunicación regular (reuniones) y el trabajo en equipo multifuncional, lo que puede ayudar a garantizar que todos estén en sintonía y trabajando hacia el mismo objetivo.

Inconvenientes:

Imprevisibilidad: debido a que los equipos ágiles se centran en ofrecer soluciones de trabajo u otros entregables lo más rápido posible, pueden tener dificultades para proporcionar cronogramas o estimaciones precisos.
Documentación limitada: los equipos ágiles pueden producir menos documentación que los equipos tradicionales, lo que puede ser un problema para las organizaciones que requieren especificaciones detalladas.
Centrarse en el corto plazo: los equipos ágiles pueden estar menos preocupados por los objetivos a largo plazo y más preocupados por ofrecer una solución funcional u otros resultados a corto plazo.
Falta de estructura: las metodologías ágiles están menos estructuradas que los enfoques tradicionales y pueden no ser apropiadas para todos los equipos u organizaciones.
Dependencia de un facilitador capacitado: las metodologías ágiles requieren el uso de un facilitador capacitado para guiar al equipo y garantizar que el proceso se siga correctamente; Si esta persona no está bien capacitada o no está disponible, el desempeño y los resultados del equipo se verán afectados.

Las metodologías ágiles necesitan un cambio cultural que ponga énfasis en la colaboración, la flexibilidad y la mejora continua. Esto puede resultar un desafío, especialmente en organizaciones más grandes con jerarquías establecidas y departamentos aislados. Con demasiada frecuencia, el "enfoque ágil" sigue siendo un eslogan, pero las organizaciones continúan operando como antes. Las empresas están volviendo a viejos hábitos debido a la falta de comprensión de una metodología ágil y de la aceptación de los empleados en todos los niveles. Además, una implementación ágil eficaz requiere la asignación de recursos adecuados, incluidos presupuesto, personal y tecnología, lo que no siempre funciona tan bien cuando los recursos son limitados.

¿Dónde podemos utilizar un enfoque ágil?

Desarrollo de productos: al priorizar las necesidades de los clientes y agilizar los procesos de desarrollo, las metodologías ágiles pueden ayudar a desarrollar y lanzar nuevos productos de forma rápida y eficaz.
Control de calidad: al agregar pruebas y retroalimentación rutinarias e iterativas al proceso de desarrollo y garantizar que se satisfagan las necesidades del cliente, los enfoques ágiles pueden ayudar a mejorar el control de calidad.
Gestión de proyectos: al ofrecer un marco flexible para la colaboración, la priorización y la mejora continua, los enfoques ágiles pueden ayudar a gestionar eficazmente proyectos complejos y multidisciplinarios.
Gestión de la cadena de suministro: al facilitar la comunicación y la colaboración en tiempo real con los proveedores, reducir los plazos de entrega y mejorar los tiempos de entrega, los enfoques ágiles pueden ayudar a mejorar la gestión de la cadena de suministro.

¿Y cómo funciona?

La gestión ágil se centra en un conjunto de principios y prácticas clave destinados a aumentar la velocidad, la eficiencia y la eficacia del desarrollo de productos. Entre estos principios y prácticas se encuentran:

Colaboración y comunicación: las metodologías ágiles ponen un fuerte énfasis en la colaboración y la comunicación entre diferentes equipos, como desarrollo de productos, ingeniería y marketing. Esto garantiza que todos trabajen para lograr los mismos objetivos y que todos sean conscientes de en qué están trabajando los demás.
Priorización del trabajo: enfatizan la priorización del trabajo en función de las necesidades del cliente, asegurando que las tareas más críticas se completen primero. Esto ayuda a garantizar que el proceso de desarrollo se centre en proporcionar valor a los clientes de la manera más eficiente posible.
Desarrollo iterativo e incremental: fomentan el desarrollo iterativo e incremental, lo que permite agregar nuevas características y funcionalidades a los productos de manera controlada e incremental. Esto reduce el riesgo y al mismo tiempo permite incorporar comentarios durante todo el proceso de desarrollo.
Mejora continua: promueven la mejora continua mediante la realización de revisiones periódicas y retrospectivas para identificar áreas de mejora y realizar cambios en el proceso de desarrollo. Esto contribuye a que el proceso de desarrollo mejore y evolucione constantemente, además de responder a las necesidades cambiantes de los clientes y las condiciones del mercado.
Flexibilidad y adaptabilidad: las metodologías ágiles proporcionan un marco flexible y adaptable para la gestión de proyectos, permitiendo cambios rápidos y fáciles a medida que hay nueva información disponible. Esto contribuye al desarrollo de productos que respondan a las necesidades cambiantes de los clientes, las condiciones del mercado y los requisitos reglamentarios.

Otra herramienta muy conocida en Agile es el Sprint Backlog, es decir, un cuadro o tabla que incluye las tareas pendientes, las tareas finalizadas y las tareas en proceso. Hay muchas herramientas online que permiten elaborar este cuadro, aunque puede realizarse también con una pizarra o superficie plana y hojas post-it.

2.2. Agile innovation

Se han creado muchas metodologías basadas en la filosofía agile. En el ámbito sanitario, por ejemplo, es muy conocida Agile Innovation.

La base de esta metodología es que los proveedores sanitarios deben cambiar su definición de innovación de la generación de ideas a métodos rápidos de realizar experimentos para probarlas. En otras palabras, la prestación de servicios sanitarios necesita un proceso participativo y centrado en el cliente para una innovación que pueda ser sostenida: es decir, replicada y repetida. Tal proceso debe permitir a los equipos en el terreno utilizar experimentación rápida, responder a problemas bien caracterizados, evaluar soluciones y gestionar el caos de los sistemas complejos adaptativos.

Las 3 bases de esta metodología son:

El pensamiento de diseño (design thinking), un enfoque creativo de resolución de problemas. Por ejemplo, incorpora el modelo iterativo.
Los principios ágiles para el desarrollo de software y la gestión de proyectos, donde los equipos trabajan intensamente en sprints de ciclo corto para producir soluciones funcionales, probarlas con los clientes y obtener comentarios para guiar el siguiente sprint.
La complejidad y las ciencias del comportamiento.

La innovación ágil tiene ocho pasos, cuatro de planificación y cuatro de ejecución. La innovación no es lineal, pero los ocho pasos generalmente se realizan en orden directo y se repiten partes del proceso según sea necesario. El flujo de proceso iterativo y cíclico de Agile Innovation se asemeja a otros enfoques iterativos como PDCA.

2.3. Scrum

Scrum es seguramente la metodología agile más conocida y utilizada. Scrum se presenta como un marco de trabajo o conjunto de prácticas efectivas para la gestión de proyectos. Está fundamentado en un estudio realizado sobre los procesos de desarrollo que resultaron exitosos en empresas como Canon, Xerox, Honda y HP en la década de 1980, las cuales en esa época eran líderes en la industria de manera similar a como Google o Apple lo son en la actualidad. Dicho estudio reveló que estos equipos altamente productivos seguían patrones de trabajo muy parecidos.

Scrum se fundamenta en la entrega regular de componentes del producto final, comenzando con las funcionalidades de mayor relevancia para el cliente. Por lo tanto, Scrum es especialmente apropiado para proyectos que requieren obtener resultados de forma rápida o en situaciones donde los requisitos cambian con frecuencia. La competitividad, la flexibilidad y la eficiencia son cruciales en este contexto.

En Scrum, se establece un proceso de trabajo basado en elementos o herramientas, una serie de reuniones programadas a lo largo del proyecto y roles claramente definidos para los participantes.

Elementos o herramientas:

Pila del Producto: Es simplemente el listado de tareas pendientes. En este catálogo se describen de manera general las características que deberá tener el producto final por completar. Este catálogo debe ser elaborado y priorizado por alguien que tenga un conocimiento profundo de las necesidades que el producto debe resolver. Mantener este catálogo de tareas visible y revisarlo periódicamente ayudará a mantener una visión clara del trabajo que queda por hacer y proporcionará un sentimiento de progreso a medida que se completen las tareas.
Pila del Sprint: A partir del listado anterior, el Responsable del Producto seleccionará un conjunto más reducido de tareas que el equipo pueda abordar durante las próximas dos semanas, conocidas como "sprints". Durante este período, el equipo trabajará intensamente para finalizar estas tareas. La duración típica de un sprint varía entre 1 y 4 semanas.
Gráfica Burndown: Al finalizar un sprint, durante la Reunión de Demostración, cuando el Responsable del Producto aprueba algunas o todas las tareas comprometidas, establece la estimación de trabajo pendiente en cero, lo que implica que hay menos tareas por completar y la gráfica disminuye (de ahí el nombre "de reducción"). Cuando la gráfica llega al punto más bajo y no quedan tareas pendientes en el Catálogo del Producto, se considera que el proyecto está terminado.

Roles:

Dueño del Producto: Es el encargado de definir y priorizar la lista de características a desarrollar en el proyecto (el Catálogo del Producto) en función de las necesidades de quien financia el producto. Aporta la perspectiva del cliente y lo que este requiere.
Scrum Master: No es exactamente el jefe de proyecto convencional. Esa responsabilidad se divide entre el propio Maestro de Scrum y el Responsable del Producto. Su misión más importante es proteger al equipo de interrupciones mientras trabajan para completar el sprint y resolver cualquier problema u obstáculo que les impida alcanzar el objetivo del sprint. Además, prepara las reuniones y se asegura de que sean productivas. También asigna tareas al equipo de Trabajo y realiza un seguimiento de las ya asignadas.
El Equipo de Trabajo: Son los miembros del equipo responsables de entregar el producto. Al final de cada sprint, deben entregar las historias de usuario revisadas y probadas.

Reuniones:

Reunión de Planificación del Sprint: Antes de comenzar el trabajo planificado para las próximas dos semanas, se llevará a cabo una reunión con el Responsable del Producto (y, si lo considera necesario, con personas del cliente) para definir la prioridad de las tareas que deben realizarse durante ese período. El Responsable del Producto proporcionará detalles sobre las tareas seleccionadas y explicará lo que sea necesario para completar el trabajo.
Reuniones Diarias: El equipo de trabajo y el Maestro de Scrum se reunirán a diario, preferiblemente al inicio de la jornada, durante 15 minutos para responder a las siguientes preguntas: ¿Qué se logró desde la última reunión? ¿Qué se hará desde ahora hasta la próxima reunión? ¿Qué está obstaculizando el trabajo de la mejor manera posible.
Reunión de Demo: Al final de cada sprint, se acuerda una fecha de reunión con el Responsable del Producto y se presenta una demostración del trabajo realizado en las últimas dos semanas. Durante esta reunión, el Responsable del Producto revisará lo que se le presenta y dará su aprobación o no a lo que ha visto. Para que la funcionalidad se considere concluida, es importante que esté completamente terminada y libre de errores.
Reuniones de Retrospectiva: Tras cada sprint y la demostración al cliente, el Maestro de Scrum y el equipo de trabajo se reúnen para analizar los problemas que pudieron haber surgido durante esas dos semanas, las razones por las que la demostración no salió tan bien como se esperaba (o salió bien), y si es posible realizar mejoras para la próxima entrega.

En esta imagen se puede observar cómo se desarrolla un proyecto de diseño de un módulo de consultas externas para una historia clínica electrónica usando Scrum:

2.4. Kanban

Kanban se compone de listas de verificación (lista de tareas a completar) y tableros (gráficos), herramientas que brindan una excelente vista del progreso de un proyecto.

Para usarlo, necesitas crear un tablero y usar una herramienta como GitScrum, que te ayuda a organizar tu flujo de trabajo y presentar tus tareas en orden, y dividirlas en tres pasos:

Por hacer: actividades que no se han iniciado
Haciendo: actividades que se están realizando
Hecho: actividades completadas

Puedes personalizar tu tablero, crear nuevos pasos, como “impedimento”, señalando que algunos procesos no se pueden continuar por algún motivo determinado, entre otros.

2.5. Kaizen

En el ámbito empresarial y en diversos sectores económicos, así como en la vida social y la sanidad, se ha popularizado la noción de "Kaizen" o "mejora continua". Esta filosofía se originó a partir de las transformaciones que Japón implementó para abordar los problemas de productividad y calidad en su industria después de la Segunda Guerra Mundial. Destacados expertos como Deming colaboraron en la formación de numerosos profesionales e ingenieros japoneses en sistemas de calidad y métodos de mejora.

El principio fundamental del Kaizen consiste en llevar a cabo mejoras incrementales, analizar los resultados de cada cambio y actuar nuevamente para introducir una nueva mejora que beneficie la productividad o la calidad de lo que se está realizando. Este enfoque de realizar cambios pequeños y continuos resulta más efectivo que implementar cambios drásticos de una sola vez. Esto ayuda a superar el temor natural al cambio y la procrastinación al comenzar a implementarlo. Estas mejoras pequeñas, cuando se realizan de manera constante, se convierten con el tiempo en hábitos que generan resultados duraderos.

El objetivo es hacer que el cambio sea tan sencillo que sea difícil cometer errores al aplicarlo. Una vez que se haya incorporado un cambio como hábito, se puede agregar una nueva mejora o ampliar el alcance de la mejora actual para seguir avanzando de manera continua. Es crucial aplicar los cambios de manera individual para evitar la complicación de saber qué cambios aplicar y cuándo hacerlo. De esta manera, es posible evaluar el impacto de cada mejora por separado. Si se implementan varias mejoras a la vez, se corre el riesgo de no saber cuál fue efectiva y cuál no, o si el efecto de una mejora anuló a la otra.

3. IMPLEMENTACIÓN Y EVALUACIÓN DE PROYECTOS

3.1. Implementación

La implementación de un proyecto se trata de liderar y motivar a las personas, junto con la coordinación de recursos humanos y otros recursos para llevar a cabo el plan. Los procesos para hacer que el proyecto suceda se pueden describir de la siguiente manera:

Ejecución del plan del proyecto: realizar las actividades planificadas en el proyecto.
Desarrollo del equipo: desarrollar las habilidades y competencias individuales y grupales para mejorar el rendimiento del proyecto.
Comunicación y distribución de información: poner a disposición de las partes interesadas la información necesaria de manera oportuna.
Gestión de partes interesadas: trabajar con las partes interesadas a medida que el proyecto avanza, fortaleciendo su compromiso, respondiendo a sus preocupaciones y supervisando cualquier cambio en las alianzas.
Gestión del cambio: abordar los desafíos del cambio que el proyecto trae para el personal y la organización.

La suma total de estas actividades puede ser abrumadora para el director de proyecto. Entonces, ¿por dónde empezar? El plan del proyecto es clave, y es en este momento cuando se hacen evidentes los beneficios de la planificación.

Cuando el director de proyecto ha sido nombrado después de la elaboración del plan, revisar el plan y cualquier caso comercial asociado es un buen punto de partida. ¿Es realista el plan? ¿Existen omisiones evidentes? ¿Alguna parte de la planificación no fue lo suficientemente detallada? ¿Las actividades del proyecto ya han comenzado? Si hay problemas con el plan al inicio de la implementación del proyecto, este es el momento de abordarlos, cuanto antes, mejor.

Para el director de proyecto, el primer paso es comprender la historia del proyecto y el contexto. Averiguar antecedentes del proyecto, cómo se desarrolló y quiénes estuvieron involucrados puede ser de ayuda más adelante si el proyecto parece encontrar obstáculos, si está siendo socavado o si sucede algo que no se puede identificar claramente.

A medida que el proyecto comienza, suele ser una buena idea pensar en los posibles riesgos y puntos problemáticos que probablemente surgirán y cómo podrían resolverse. Esto requiere escuchar cuidadosamente, pensar de forma objetiva (sin sesgos) y realizar un análisis lógico informado. Puede ser útil alejarse de las preocupaciones diarias y analizar realmente lo que está sucediendo en el entorno del proyecto y de dónde es probable que provengan los problemas. Un método es contarse a sí mismo la historia de cómo este proyecto tiene éxito: ¿cuáles son los retos clave que se resuelven y los puntos de inflexión que marcarán la diferencia? Esta técnica también se puede utilizar para identificar los aspectos negativos: si este proyecto fracasara, ¿cuáles serían las causas y quiénes serían los villanos de la historia? Estas técnicas son una especie de ensayo para la gestión y liderazgo del proyecto, y también se pueden utilizar en la preparación de presentaciones o reuniones importantes.

Una de las tareas de liderazgo más desafiantes es asegurarse de que el equipo del proyecto se adapte a las circunstancias y esté constantemente evaluando y perfeccionando los métodos y enfoques en constante evolución del proyecto. El aprendizaje en acción (o la práctica reflexiva relacionada) es un enfoque que puede ser útil para esta tarea. El aprendizaje en acción es la práctica de la reflexión cuidadosa (y la discusión) de los eventos, un proceso mediante el cual las personas dan sentido a su experiencia y su significado.

Los directores de proyecto pueden promover el aprendizaje en acción en sus equipos mediante el simple método de fomentar la discusión reflexiva y el análisis de cualquier aspecto del proyecto que parezca problemático o potencialmente gratificante, o que pueda considerarse un "incidente crítico" (por ejemplo, una retirada de una parte interesada). Las reuniones regulares del equipo se pueden utilizar tanto para abordar los asuntos normales del proyecto como para fomentar la reflexión y el aprendizaje. El principal desafío de esta técnica es establecer un entorno de confianza y seguridad para que los miembros del equipo puedan participar en una discusión abierta y reflexiva, y luego mantener un clima de seguridad a través del compromiso mutuo con la confidencialidad y el uso constructivo de los resultados de la discusión. Al comienzo del proyecto y cuando se establece el equipo, puede ser útil llevar a cabo un proceso de inducción y orientación del proyecto donde se pueda discutir el "código de conducta" del proyecto.

Durante el transcurso del proyecto, puede volverse evidente que el equipo del proyecto tiene brechas en sus habilidades y conocimientos, o pueden surgir conflictos entre los miembros del equipo o con otros grupos e individuos. Esto puede ser uno de los desafíos más difíciles que un gerente debe enfrentar, dentro o fuera de un proyecto. Si bien existen muchas técnicas y métodos para lidiar con el conflicto, las habilidades básicas de resolución de problemas son particularmente relevantes.

Es importante mantener una mente abierta para reconocer los problemas a medida que comienzan a surgir en el equipo del proyecto. Sugerimos el siguiente proceso de resolución de problemas:

Aceptar que existe un problema y tomar medidas para abordarlo.
Recopilar objetivamente los hechos.
Definir el problema.
Comprender qué está causando el problema.
Involucrar al equipo en contribuir tanto a la comprensión del problema como a la búsqueda de soluciones.
Acordar la solución.
Planificar la respuesta e implementarla.

Una de las razones por las que muchos procesos de cambio fallan es que los promotores no comprenden la política del cambio. El sector de salud y servicios comunitarios está compuesto por muchos interesados poderosos que no siempre tienen los mismos intereses y a menudo compiten entre sí por el poder y el prestigio. Las organizaciones deben gestionar las tensiones entre proporcionar un servicio y equilibrar un presupuesto, entre su política proclamada y su práctica real, entre el centralismo y el localismo, entre profesionales y gerentes, y entre innovación y tradición y comodidad.

Si bien algunos elementos de la estructura de poder (como jerarquías formales, controles y asignación de recursos) son evidentes, gran parte de la política de la organización y del proyecto ocurre en lo se llama el "lado sombra". Se puede definir como "todas las actividades y relaciones importantes que no se identifican, discuten y gestionan en los foros de toma de decisiones que pueden marcar la diferencia. El lado sombra se ocupa de lo encubierto, lo no discutido, lo indiscutible y lo inconfesable. Incluye acuerdos que no se encuentran en manuales organizativos y documentos de la empresa ni en organigramas organizativos".

El lado sombra, o el sistema en la sombra está fuera de la intervención directiva habitual y puede afectar sustancialmente la productividad y la calidad de vida laboral, tanto de manera positiva como negativa. Gran parte de lo que constituye una cultura organizativa de apoyo son elementos positivos y poderosos del lado sombra. Otros aspectos positivos incluyen la defensa informal en nombre de la organización, que muchos empleados realizan tanto dentro como fuera del entorno laboral, y las redes informales de comunicación que fluyen por debajo y alrededor de los canales formales y ayudan tanto a los gerentes como al personal a saber lo que está sucediendo.

Los elementos negativos pueden incluir:

Enemistad arraigada entre gerentes funcionales (afectando la capacidad de sus departamentos para trabajar juntos).
Una cultura que acepta un bajo rendimiento por parte de individuos favorecidos.
Miembros ejecutivos o de la junta influenciados en su toma de decisiones por lealtad a una fuerza externa (como su asociación profesional o los intereses de su familia) en lugar de la organización.
Procesos de aprobación que no se comprenden ni se documentan.
Manipulación de agendas y actas de reuniones (asuntos que no se discuten en absoluto o discusión no registrada con precisión).

Siempre habrá un lado sombra, y las organizaciones siempre tendrán política. La pregunta no es si, sino hasta qué punto y en qué direcciones (útiles o perjudiciales) opera la política organizativa. Una buena gestión, tolerancia a la diferencia y el debate, y la comunicación abierta tienden a minimizar el espacio en el que el lado sombra tiene que operar. Es decir, sacar a la luz cuestiones importantes y tratarlas de manera cuidadosa reducirá la necesidad de actividad negativa en el lado sombra. Los proyectos pueden ser una oportunidad para poner el foco en armarios olvidados y áticos remotos en la organización, y para abordar de manera constructiva cuestiones del lado sombra (pero se necesita juicio para decidir qué puertas abrir y cuándo).

Cuando se proponen cambios, las personas que se verán afectadas comienzan a calcular las ganancias y pérdidas en relación con dos preguntas básicas: '¿Qué hay para mí?' y '¿Realmente sucederá?'. Hay algunas buenas razones para la tendencia a resistirse al cambio. Aquellos que se sienten cómodos con la forma en que están las cosas a menudo verán, quizás correctamente, que tienen algo que perder, incluyendo parte del poder o influencia que tienen actualmente. Y a menudo tendrán algún poder que pueden utilizar para resistir.

Por otro lado, aquellos que se benefician de un cambio propuesto, ya sea personalmente o porque están de acuerdo con los objetivos del cambio, se encuentran en una posición de incertidumbre. Su apoyo activo generalmente depende no solo de si pueden ver que hay algo para ellos, sino también de si creen que realmente sucederá.

3.2. Evaluación y seguimiento

El control de un proyecto consiste en garantizar que se cumplan sus objetivos mediante la supervisión y medición regular del progreso para identificar desviaciones del plan y tomar medidas correctivas cuando sea necesario. Los métodos y herramientas son importantes para el control y monitoreo, y las decisiones deben tomarse lo antes posible sobre cuáles se utilizarán. Algunas organizaciones tienen métodos obligatorios que utilizan para este propósito, y en otras hay flexibilidad para mezclar y combinar herramientas según las necesidades del proyecto. Los directores de proyectos pueden necesitar importar o desarrollar sus propias plantillas, formularios y procesos de recopilación y presentación de datos.

La información para un buen sistema de control debe ser visible, precisa, confiable, válida, oportuna y tanto diagnóstica (¿qué está sucediendo?) como pronóstica (¿qué impacto tendrá?). Y debe adaptarse a las necesidades del proyecto en función del plan del proyecto. El plan cubrirá todos los parámetros del proyecto que requieren monitoreo, lo que permitirá el diseño de un sistema de informes y monitoreo.

El plan de evaluación también resaltará las áreas requeridas de enfoque para la recopilación y análisis de datos. Aunque exactamente lo que necesita ser monitoreado depende en gran medida de la naturaleza del proyecto, es probable que se monitoreen datos sobre gastos (en comparación con el presupuesto), la finalización de tareas/actividades (en comparación con el cronograma) y el rendimiento (en comparación con las especificaciones).

Hay varios aspectos de cualquier proyecto que serán desafiantes de monitorear y controlar. Abordamos brevemente el control del alcance y el cronograma, el presupuesto y los recursos, la calidad del proyecto, el riesgo y las contingencias, antes de abordar el desafío de gestionar proyectos cuando surgen problemas.

Durante la fase de implementación en cualquier proyecto, los cambios en el plan (llamados "varianzas" o "variaciones") son normales y se esperan. Si hay varianzas significativas (y ponen en peligro los objetivos del proyecto), el plan se puede ajustar repitiendo el proceso de planificación relevante, por ejemplo, reestimando los niveles de personal. Es casi inevitable que tan pronto como se haya escrito y aprobado el plan del proyecto y el alcance, ocurran cambios. El problema importante para el control es asegurarse de que las varianzas se documenten, el plan se ajuste en consecuencia y la variación se acepte formalmente por el grupo o individuo autorizado.

El alcance acordado, planificado y documentado en la fase de planificación puede ser cuestionado o requerir modificaciones por razones legítimas. Puede haber un cambio en el contrato, los entregables, el grupo de implementación objetivo, el presupuesto y el cronograma, por nombrar algunos. Por ejemplo, durante la implementación de un sistema de información, puede ser necesario incluir más funcionalidades para que el sistema funcione; o el momento de la puesta en marcha podría necesitar extenderse para asegurarse de que se solucionen todos los defectos y problemas. Sin embargo, el "alcance no gestionado" (expansión no gestionada del alcance del proyecto) es una amenaza común y grave, que lleva a desbordamientos de costes, incumplimiento de plazos y expectativas no cumplidas.

Las herramientas para gestionar y controlar el alcance del proyecto incluyen:

Un proceso de solicitud de cambio, que comúnmente utiliza un formulario de solicitud de cambio.
Un proceso para evaluar el impacto del cambio en el proyecto, como el impacto en el presupuesto o el cronograma.
Revisión y aprobación formales de las solicitudes de cambio por parte del comité de dirección, que luego otorga autoridad al director del proyecto para revisar el proyecto en consecuencia o negarse a hacerlo.

La definición operativa del éxito del proyecto, al igual que el proyecto en sí, es única. Aunque el "triángulo de hierro" genérico de coste, tiempo y especificaciones es un punto de referencia útil, los proyectos reales tienen más sabor y textura, así como resultados que van más allá de los entregables del proyecto. Los interesados tienden a evaluar el éxito en función de sus intereses y perspectivas.

Por ejemplo, existe evidencia de que el "apoyo de la alta dirección", generalmente citado como algo necesario para el éxito, a menudo es una medida dominante del éxito, es decir, el proyecto es un éxito si los líderes creen que lo es.

Cuando un proyecto ha completado su curso, el proceso de finalización y cierre (a veces llamado "cierre") es un paso final importante. Los criterios para la finalización del proyecto se definen en el plan del proyecto, generalmente como la finalización de todas las tareas en el plan y el logro de los resultados y entregables planificados.

La naturaleza de las tareas de finalización y su momento variará, pero se dividen en tres categorías principales: aceptación y entrega (la finalización práctica), completar la evaluación y el informe final. Si un proyecto va a ser silenciosamente abandonado, las tareas de finalización son algo diferentes.

Cuando un proyecto fracasa se suele atribuir el fracaso a deficiencias en la planificación, priorización y dotación de recursos de los proyectos. La falta de definición clara de los objetivos y el alcance, con el resultado de que el proyecto se sale de control y luego es difícil de detener, es una historia típica. Las razones del fracaso del proyecto son, en muchos aspectos, el reflejo de los indicadores de éxito. Por ejemplo, la Oficina Nacional de Auditoría del Reino Unido después de revisar proyectos de tecnología de la información en el sector público, enumeró estos factores:

Falta de una conexión clara entre el proyecto y las prioridades estratégicas clave de la organización, incluidas las medidas acordadas de éxito.
Falta de propiedad y liderazgo claros por parte de la alta dirección y/o ministros.
Falta de participación efectiva de las partes interesadas.
Falta de habilidades o un enfoque probado para la gestión de proyectos y la gestión de riesgos.
Falta de comprensión y contacto con la industria proveedora a nivel directivo en la organización.
Evaluación de propuestas impulsadas por el precio inicial en lugar del valor a largo plazo (especialmente la entrega de beneficios comerciales).
Prestar poca atención a la división del desarrollo y la implementación en pasos manejables.
Recursos y habilidades inadecuados para la entrega de todos los resultados requeridos.

Si un proyecto no ha tenido éxito o está avanzando sin un claro camino hacia la finalización, la mejor opción puede ser abandonarlo o darlo por terminado. Los proyectos pueden fracasar de muchas maneras, desde la escalada ("solo una milla más") hasta cambios graves en el entorno. Cuando las barreras son insuperables o cuando los esfuerzos de rescate han fallado, la única alternativa puede ser dar por terminado el proyecto, interrumpir el trabajo y reasignar a las personas que estaban trabajando en él. El cierre de un proyecto también puede ser una contingencia planificada, por ejemplo, cuando los resultados de una etapa del proyecto indican un fallo fatal en su diseño o viabilidad, y la decisión de no continuar con las etapas posteriores es la única opción.

Las variedades de terminación de proyectos son la extinción, adición, integración e inanición. La extinción significa que el proyecto se detiene (ya sea exitoso o no exitoso). La adición significa que el proyecto se incorpora a las operaciones continuas como una unidad o departamento distinto en la organización. La integración es cuando el proyecto desaparece pero sus elementos se distribuyen dentro de la organización, y la inanición es cuando el proyecto todavía existe pero los recortes presupuestarios significan que no se avanza.

Un reciente proyecto digital del Melbourne Children Campus indicó en su evaluación las siguientes lecciones aprendidas:

Mantener un enfoque centrado en el problema y no descuidar la etapa inicial de exploración.
Asegurarse de obtener un compromiso genuino y representación de todas las partes interesadas relevantes mediante la creación de un equipo interdisciplinario de consultores pertinentes con experiencia en desarrollo de software, traducción de conocimientos, cambio de comportamiento, estadísticas, economía de la salud, procesos regulatorios y atención médica.
Presupuestar con precisión y considerar los costes "ocultos".
Estandarizar procesos y recursos para una audiencia variada (clínicos, investigadores) para desarrollar, evaluar e implementar soluciones.
Desarrollar un marco de evaluación que se adapte a su contexto local, sea flexible y aplicable a contenidos de salud digital.
Realizar una evaluación exhaustiva en cada etapa del proceso.

3.3. Proyectos de salud digital

La adopción de tecnología en la atención de salud ocurre comúnmente bajo uno de dos escenarios: “empuje o impulso de tecnología” o “atracción de demanda”. Los escenarios de impulso tecnológico se dan cuando un proveedor de tecnología ha negociado un proyecto piloto en un entorno clínico, a menudo con un directivo o mando intermedio que toma decisiones pero que no utilizará directamente el producto. En estos casos, las personas que utilizarán el producto aún no han comprendido su valor antes de tomar la decisión de adquirirlo. En términos generales, este escenario hace que la adopción sea más desafiante.

El escenario de demanda es donde un equipo de profesionales en una organización sanitaria identifica un problema al que se enfrentan en su servicio. Analizan la naturaleza del problema e identifican un tipo particular de tecnología que podría ayudar a resolverlo. Una vez realizado este trabajo, el equipo identifica una herramienta particular que satisface una necesidad existente y bien definida.

En la implementación de proyectos digitales es habitual utilizar herramientas de la metodología “service design” y de la propuesta de valor (que se ha comentado en otro módulo). El “diseño de propuesta de valor” es una metodología para establecer el valor real de un nuevo producto o proceso para la variedad de personas con las que interactúa ese producto o proceso. Los desarrolladores de nuevas herramientas digitales generalmente tienen una opinión clara sobre el valor de su producto, pero es probable que ese valor no sea interpretado de la misma manera por todos los pacientes, médicos y pagadores.

Este modelo presenta un marco de trabajo muy sencillo compuesto por 3 componentes: Herramienta+Equipo+Rutina:

Herramienta: ¿Existe una propuesta de valor claramente expresada para todos aquellos que deben interactuar con la plataforma digital? ¿Ven los profesionales cómo la plataforma mejorará su capacidad para atender a los pacientes?
Equipo: Dos puntos de partida clave se relacionan con el equipo: si todo el equipo está de acuerdo en que hay un problema que vale la pena resolver y el impacto que tendrá la herramienta digital para las relaciones entre los miembros del equipo.
Rutinas. ¿Cómo afecta a los procesos habituales para prestar el servicio?

Otro modelo de implementación específico de proyectos de salud digital es el modelo NASS. Este modelo de adopción de tecnologías tiene 7 dominios: enfermedad, tecnología, propuesta de valor, agentes, organización, contexto, adaptación a lo largo del tiempo.

Este último punto es específico del ámbito de la salud y se relaciona con dos conceptos como son el "potencial de reinventarse" y la noción de resiliencia organizativa, que se ha definido como la capacidad de un sistema para ajustar su funcionamiento antes, durante o después de cambios y perturbaciones, de modo que pueda mantener operaciones necesarias, incluso después de un incidente importante o en presencia de estrés continuo.

4. RECURSOS COMPLEMENTARIOS RECOMENDADOS

Metodologías ágiles para mejorar la salud https://www.youtube.com/watch?v=RYb48CqSQDI
Vídeo práctico sobre agile y Kanban https://www.youtube.com/watch?v=6ZBIE0XJU1M
Vídeo TED “Agile en la vida diaria” https://www.youtube.com/watch?v=nGw23NDzRrg
¿Qué es Scrum? - WEBINAR COMPLETO en ESPAÑOL https://www.youtube.com/watch?v=WZ8U_NHVdhI
Web Mamá qué es Scrum (Agile y Scrum como camino para la Transformación Digital) https://mamaqueesscrum.com/

BIBLIOGRAFÍA

Campanella, P., Lovato, E., Marone, C., Fallacara, L., Mancuso, A., Ricciardi, W., & Specchia, M. L. (2016). The impact of electronic health records on healthcare quality: a systematic review and meta-analysis. The European Journal of Public Health, 26(1), 60-64.
Carnicero, J., & Fernández, A. (2012). Manual de salud electrónica para directivos de servicios y sistemas de salud.
Cortés, L. P. (2016). OpenEHR y otros Estándares para la Historia Clínica Electrónica, Núcleo Esencial del Sistema de Información Hospitalaria. Revista Salud y Administración, 3(7), 33-47.
Negro-Calduch E, Azzopardi-Muscat N, Krishnamurthy RS, Novillo-Ortiz D. Technological progress in electronic health record system optimization: Systematic review of systematic literature reviews. Int J Med Inform. 2021;152:104507
Neves, A. L., Freise, L., Laranjo, L., Carter, A. W., Darzi, A., & Mayer, E. (2020). Impact of providing patients access to electronic health records on quality and safety of care: a systematic review and meta-analysis. BMJ quality & safety, 29(12), 1019-1032.
Nittas, V., Lun, P., Ehrler, F., Puhan, M. A., & Mütsch, M. (2019). Electronic patient-generated health data to facilitate disease prevention and health promotion: scoping review. Journal of medical Internet research, 21(10), e13320.
Peña, J. L. M., & Salvador, C. H. (2003). Estándares para la historia clínica electrónica. Informes SEIS, 193.
Rodríguez, R. A., Alfaro, I. G., Toledo, R. B., & Rodríguez, J. C. (2021). Historia clínica y receta electrónica: riesgos y beneficios detectados desde su implantación. Diseño, despliegue y usos seguros. Aten. Primaria, 53, 102220.
Roman LC, Ancker JS, Johnson SB, Senathirajah Y. Navigation in the electronic health record: A review of the safety and usability literature. J Biomed Inform Eíto-Brun, R., & Méndez-Solar, J. (2017). Normas técnicas para historia clínica electrónica en el proyecto HCDSNS. Profesional de la información, 26(6), 1199-1210.2017;67:69-79
Ruiz-Lopez, P., & Aranaz, J. (2017). La gestión sanitaria orientada hacia la calidad y seguridad de los pacientes. Fundación Mapfre.
World Health Organization. (2008). Framework and standards for country health information systems. World Health Organization.
Agencia Española de Protección de Datos (2019). Guía para pacientes y usuarios de la sanidad. Online. Accesible en: https://www.aepd.es/sites/default/files/2019-12/guia-pacientes-usuarios-sanidad.pdf
Antomás, J., & Huarte del Barrio, S. (2011, April). Confidencialidad e historia clínica: Consideraciones ético-legales. In Anales del sistema sanitario de Navarra (Vol. 34, No. 1, pp. 73-82).
Bertran et al (2005). Intimidad, confidencialidad y secreto. Guías de ética en la práctica médica. Fundación de ciencias de la salud.
Carnicero, J., & Fernández, A. (2012). Manual de salud electrónica para directivos de servicios y sistemas de salud.
Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos Personales y garantía de los derechos digitales. Boletín Oficial del Estado número 294, de 6 de diciembre de 2018.
Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional de Seguridad. Boletín Oficial del Estado número 106, de 04 de mayo de 2022.
Reglamento (UE) 2016/679 del Parlamento Europeo y del Consejo, de 27 de abril de 2016, relativo a la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos y por el que se deroga la Directiva 95/46/CE. Diario Oficial de la Unión Europea número 119, de 4 de mayo de 2016.
VVAA 2016). Smart Hospitals: Security and Resilience for Smart Health Service and Infrastructures. European Union Agency For Network And Information Security. Online. Accessible en: https://www.enisa.europa.eu/publications/cyber-security-and-resilience-for-smart-hospitals
VV.AA (2017). Ética en el acceso y en el uso de la documentación clínica. Xunta de Galicia.
VVAA (2020). Requisitos de seguridad para Aplicaciones de Cibersalud en el contexto del ENS. Centro Criptológico Nacional. Online. Accesible en:
https://www.ccn-cert.cni.es/series-ccn-stic/800-guia-esquema-nacional-de-seguridad/5326-ccn-stic-857-requisitos-seguridad-para-aplicaciones-cibersalud/file.html
Borges do Nascimento, I.J., Abdulazeem, H., Vasanthan, L.T. et al. Barriers and facilitators to utilizing digital health technologies by healthcare professionals. npj Digit. Med. 6, 161 (2023).
Cornellà A (2019). Cómo innovar: modelos y herramientas. Profit Editorial.
Gray, D., Brown, S., & Macanufo, J. (2012). Gamestorming: 83 juegos para innovadores, inconformistas y generadores del cambio. Grupo Planeta (GBS).
Greenhalgh, T., Robert, G., Bate, P., Macfarlane, F., & Kyriakidou, O. (2008). Diffusion of innovations in health service organisations: a systematic literature review.
Michalko, M. (2000). Thinkertoys. Gestión 2000.
Mootee I (2016). Design thinking para la innovación estratégica. Editorial Empresa Activa.
Nilsen, P., Seing, I., Ericsson, C. et al. Characteristics of successful changes in health care organizations: an interview study with physicians, registered nurses and assistant nurses. BMC Health Serv Res 20, 147 (2020)
Robbins, S. P. (2004). Comportamiento organizacional. Pearson educación.
Sarkar, S., & Mateus, S. (2022). Doing more with less-How frugal innovations can contribute to improving healthcare systems. Social Science & Medicine, 306, 115127.
Smith, R., King, D., Sidhu, R., & Skelsey, D. (Eds.). (2014). The effective change manager's handbook: Essential guidance to the change management body of knowledge. Kogan Page Publishers.

Chettipally, U. K. (2023). Digital Health Entrepreneurship. Springer International Publishing.
Cortez, N. (2018). Digital Health: Scaling Healthcare to the World. Springer.
Coskun-Setirek, A., & Tanrikulu, Z. (2021). Digital innovations-driven business model regeneration: A process model. Technology in Society, 64, 101461.
de Kok, E., Weggelaar‐Jansen, A. M., Schoonhoven, L., & Lalleman, P. (2021). A scoping review of rebel nurse leadership: Descriptions, competences and stimulating/hindering factors. Journal of clinical nursing, 30(17-18), 2563-2583.
Hernández Ortiz et al. (2017). Guía para crear una empresa en la UJA. Universida dde Jaén.
Kelley, L. T., Fujioka, J., Liang, K., Cooper, M., Jamieson, T., & Desveaux, L. (2020). Barriers to creating scalable business models for digital health innovation in public systems: qualitative case study. JMIR Public Health and Surveillance, 6(4), e20579.
Kelly, L., Medina, C., & Cameron, D. (2014). Rebels at work: A handbook for leading change from within. O'Reilly Media, Inc.
ONTSI (2019. Barómetro del emprendimiento en España. Online. Accesible en: https://www.ontsi.es/sites/ontsi/files/2019-12/BarometroEmprendimiento_ConceptosIndicadores_diciembre2019.pdf
Osterwalder, A., & Pigneur, Y. (2010). Business model generation: a handbook for visionaries, game changers, and challengers (Vol. 1). John Wiley & Sons.
Osterwalder, A., Pigneur, Y., Bernarda, G., & Smith, A. (2015). Value proposition design: How to create products and services customers want (Vol. 2). John Wiley & Sons.
Steinberg, D., Horwitz, G., & Zohar, D. (2015). Building a business model in digital medicine. Nature biotechnology, 33(9), 910-920.
VVAA (2020). Creando valor: Guía de herramientas y recursos para el emprendimiento social. Dirección General de Empresa (Junta de Extremadura). Online. Accesible en https://proyectoefes.es/wp-content/uploads/2020/05/guia-creando-valor-castellano-1.pdf
Wirtz, B. W. (2019). Digital business models: Concepts, models, and the alphabet case study. Springer.
Bin, K. J., Higa, N., da Silva, J. H., Quagliano, D. A., Hangai, R. K., Cobello-Júnior, V., ... & Ono, S. K. (2021). Building an outpatient telemedicine care pilot using Scrum-like framework within a medical residency program. Clinics, 76.
Crotty, B. H., Somai, M., & Carlile, N. (2019). Adopting agile principles in health care. Health Affairs Forefront.
Figueroa, W., Pérez, M., Castillo, F., Gómez, R., & Sosa, E. (2021). Metodología SCRUM aplicada en el desarrollo del módulo de Consulta Externa del Sistema Integral Hospital Rovirosa (SIHR). Innovación y Desarrollo Tecnológico Revista Digital, 379-393.
Greenhalgh, T., & Abimbola, S. (2019). The NASSS framework-a synthesis of multiple theories of technology implementation. Stud Health Technol Inform, 263, 193-204.
Holden, R. J., Boustani, M. A., & Azar, J. (2021). Agile Innovation to transform healthcare: innovating in complex adaptive systems is an everyday process, not a light bulb event. BMJ Innovations, 7(2).
Hourani, D., Darling, S., Cameron, E., Dromey, J., Crossley, L., Kanagalingam, S., ... & Anderson, V. (2021). What Makes for a Successful Digital Health Integrated Program of Work? Lessons Learnt and Recommendations From the Melbourne Children's Campus. Frontiers in Digital Health, 3, 53.
Houston, S. M. (2021). The Project Manager's Guide to Health Information Technology Implementation. CRC Press.
Kokol, P., Blažun Vošner, H., Kokol, M., & Završnik, J. (2022). Role of agile in digital public health transformation. Frontiers in Public Health, 10, 899874.
Schwaber, K., & Sutherland, J. (2020). La guía definitiva de Scrum: las reglas del juego.
Shaw, J., Agarwal, P., Desveaux, L., Palma, D. C., Stamenova, V., Jamieson, T., ... & Bhattacharyya, O. (2018). Beyond “implementation”: digital health innovation and service design. NPJ digital medicine, 1(1), 48.