Es este contexto tan hostil, ¿existirá alguna metodología o proceso que nos acerque al éxito o nos aleje del fracaso?. El objetivo de este artículo es dar mi opinión personal sobre algunas "áreas sensibles" que los gestores de proyectos deberían cuidar para que "el bote no haga agua".
Algunos de estos puntos podrán coincidir más o menos con los métodos y estrategias usados por los gestores de proyectos, y deberían considerarse como la humilde opinión de alguien que observa y analiza la realidad (de cerca), no como una solución a todos los problemas. Además trato de hacer énfasis en el "qué", no en el "cómo", pero la discusión está abierta.
El proyecto debería ser solo un grano de arena
El proyecto de informatización debe ubicarse en una estrategia organizacional de mejora, el proyecto no debería ser la estrategia, sino un resultado de esta.
Tener claro este punto facilita que el apoyo de los tomadores de decisión de la institución se haga visible, y ubica al proyecto en un lugar de la agenda institucional. De lo contrario, el apoyo se hace esquivo, y no se tiene una puerta donde ir a tocar cuando hay problemas a nivel de la institución.
La informatización es un camino solo de ida
Junto a la planificación de las distintas etapas de desarrollo e implantación de las soluciones informáticas en el área clínica, debería planificarse la estrategia de eliminación del papel de los procesos clínicos.
Dejar "vivo" al papel es atentar contra el uso de los productos del proyecto.
Evitar el proyecto de duración infinita
Todo gestor de proyectos sabe que un elemento característico de éstos es que tienen una fecha de fin.
Esa fecha de fin debería ser fija e inamovible, y se debería tener claro qué es lo que se va a entregar y qué es lo que no. Tres factores se debe tener en cuenta siempre: el alcance (cantidad y complejidad de necesidades a satisfacer), la calidad (cantidad de ciclos de mejora sobre una necesidad satisfecha) y el tiempo (demora en satisfacer una necesidad o de mejorar la forma en la que esta es satisfecha). Se dice que tenemos 3 balas y solo podemos disparar 2, por ejemplo un proyecto con un alcance muy grande y con gran calidad, requerirá mucho tiempo en desarrollarse. Otra posible combinación es que si tenemos poco tiempo y un alcance fijo, no podemos pedir mucha calidad. La regla general es que si aumentamos alcance, calidad o tiempo, aumenta el costo/presupuesto.
Siempre hay aspectos que pueden mejorar, y siempre habrá tiempo para mejorarlos, pero sobre la entrega de los productos no podemos empezar procesos de mejora. Es mucho mejor para el proyecto, para el proveedor y para el cliente: 1. entregar lo pactado, ni más ni menos; 2. aceptar lo que se debe entregar; 3. cerrar el proyecto; 4. sentarse a pensar en mejoras (...y ver si queda algo de presupuesto).
Las expectativas y la comunicación son también elementos a gestionar
Luego de fijar el alcance del proyecto, los clientes y los usuarios finales deberían saber qué es lo que se va a entregar y cuándo. Esto incluye el saber que es lo que NO se va a entregar.
La comunicación de estos elementos se debería hacer en cada oportunidad que se tenga, y si no se dan estas oportunidades, se deben crear. Por otro lado, todos los usuarios finales (sobre todo los médicos) tienen una idea de lo que quieren, y todos se imaginan que el producto será exactamente como ellos lo imaginan. Para evitar desilusionar a estos usuarios (riesgo a rechazo del producto), se debe dar una imagen clara del producto, de lo que tendrá y no tendrá, y bajar o subir las expectativas al nivel correcto. Esto también debería hacerse en todas las oportunidades que se tengan.
Contraparte es algo más que once letras
Sin contraparte no existe proyecto. Si somo un proveedor de software, la contraparte está formada por los tomadores de decisión, los usuarios finales y el staff informático del cliente. El cliente debe ser comunicado claramente de que para que el proyecto sea un éxito, se necesita tiempo de trabajo de los recursos humanos de la institución: médicos, enfermeras, técnicos, informáticos, etc.
Una forma de que el cliente tome conciencia de esta necesidad es que sepan claramente cómo será el proceso de desarrollo e implantación de los productos del proyecto, y que en cada una de esas etapas se requerirá la participación de ciertos roles claves, que necesitan un tiempo asignado a esas tareas, y que deberán dejar de hacer otras tareas que hoy tienen asignadas.
Este punto es tan obvio que muchas veces los gestores lo pasan por alto, y como consecuencia se pierde tiempo por no contar con alguien del otro lado a quien hacerle preguntas o con quien discutir posibles soluciones a los problemas que el propio cliente plantea.
Mantener las audiencias y el interés es un gran punto a favor
En los proyectos de informatización en salud se tienen dos grandes audiencias: los tomadores de decisión y los usuarios finales. Es frecuente que por la poca visibilidad del proyecto y sus avances, por la poca comunicación, o a veces por la duración tan prolongada de estos proyectos, las audiencias que antes nos apoyaban, aportaban y se interesaban por el proyecto, ya no están tan interesados.
Perder el interés de las audiencias, es perder apoyo y ganar resistencia, lo que es un gran punto en contra para el proyecto. El interés es otro punto a gestionar y cuidar, porque hay que recuperarlo antes de que sea demasiado tarde, por ejemplo: que se entregue el producto y nadie lo use.
A los gestores les gusta saber que se tienen productos listos, y a los usuarios les gusta dar su opinión y ver como esta repercute en el producto que van a usar. Ellos debe participar en todas las etapas del proyecto!.
El proyecto
La informática es un camino para lograr un objetivo, no debería ser considerado como el objetivo en si.
Tanto los tomadores de decisiones como los usuarios finales no deberían hablar de bases de datos ni servidores, con ellos y a ellos siempre se les debería hablar en un plano médico de usos y funcionalidades que soportará la herramienta. Como estrategia general, el proyecto debería presentarse como un proyecto médico, no un proyecto informático.
El paradigma del hiper-mercado vs. las pequeñas tiendas especializadas
Existen dos formas de encarar los proyectos de informatización en salud. El primero y más frecuente, es el de una gran herramienta centralizada, con una única base de datos, que provee soporte a diferentes sectores y diferentes usuarios. Donde los requisitos y necesidades de cada uno de estos sectores y usuarios es esencialmente distinto al de los demás. Este tipo de proyectos suele ser desarrollado en un largo período de tiempo, lo que contribuye a la pérdida de interés que mencioné antes. Este producto es el hiper-mercado.
Por otro lado, está el enfoque de partir el "problema" en pedazos, el clásico "divide y vencerás" (que muchas veces olvidamos al gestionar proyectos). La idea es desarrollar pequeñas herramientas, especializadas a cada sector o tipo de usuario, y con independencia de las demás herramientas, sectores y usuarios. Este tipo de herramientas son más sencillas de desarrollar, tienen un público objetivo acotado, un tiempo de desarrollo más pequeño, y por lo tanto un riesgo menor de fallar como proyecto. Por otro lado, este enfoque agrega un elemento nuevo: es necesario pensar en estándares e interoperabilidad para que estas herramientas puedan compartir información para lograr una verdadera sinergia. Estas son las pequeñas tiendas donde cada uno encuentra exactamente lo que quiere y necesita.
Este segundo es mi enfoque preferido, ya que como gestores nos permite concentrarnos en un elemento acotado a la vez, y nos permite hacer lo mejor en cada uno, a la vez que no perdemos de vista el proyecto global.
El éxito del proyecto no debería medirse en cantidades de usuarios o registros
Muchos gestores, para mostrar el éxito de sus proyectos muestran resultados numéricos como la cantidad de usuarios, la cantidad de registros clínicos, la cantidad de prescripciones electrónicas que fueron hechas, etc.
Si bien esos valores nos sirven para medir niveles de uso (cosa que se debe hacer frecuentemente), el éxito de un proyecto no se debería medir en esos términos, sino que debería medirse en los términos de "cómo ayudaron los productos del proyecto en alcanzar os objetivos organizacionales (tanto clínicos como de gestión)". Recordemos que estos proyectos son herramientas para lograr objetivos, y que sin estrategias organizacionales y objetivos de mejora estos proyectos no existirían. Por lo tanto deberíamos preguntarnos cosas como: con estas herramientas ¿cómo se aumenta la calidad de la asistencia a los pacientes? o ¿cómo se mejora el uso de recursos limitados?
Como siempre: ¡sus comentarios son muy bienvenidos!
Hasta la próxima.
Entradas
Excelente articulo Mr. Pablo. Me gustaría saber de tu experiencia, las herramientas y el como lograrías obtener un mayor interes por parte de los stakeholders en un hospital publico, asi como que tecnicas de "persuasion" ocupar para hacer ver, de mejor forma los beneficios que conlleva la informatizacion hospitalaria vs el "temible" presupuesto que este requiere.
ResponderEliminarGracias y Saludos
Gracias por comentar Ery.
ResponderEliminarLa verdad es que en gestión de proyectos no hay técnicas, prácticas, procesos o trucos que garantices efectividad en cualquier contexto.
A veces por obvias, hay cosas que se nos escapan: si hay que mantener el interés, hay que comunicar, si hay que comunicar hay que 1. llegar al público, 2. emitir un mensaje claro, 3. verificar que el mensaje fue entendido. Nada nuevo, simplemente el viejo y querido proceso de comunicación.
Para lograrlo es fácil, levantar el teléfono más seguido y llamar, otra es ir y hablar cara a cara. Estas son las únicas formas efectivas de comunicarse con los médicos (los mails no funcionan).
Más hacia lo que es gestión, hay algunas reglas básicas como: lo que no se planifica, no se hace. Si uno como gestor sabe que debe mantener el interés de los stakeholders, entonces debe tener tareas de comunicación en el cronograma, se deben tener recursos humanos asignados a esas tareas, y por supuesto contar con presupuesto.
El presupuesto no es tan temible, si el alcance está bien definido y acotado. Muchas veces se cae en presupuestos temibles justamente por la falta de definición de los alcances. Por eso mi estrategia preferida es divide y vencerás (dividir el proyecto grande en pequeños proyectos/productos, hacer liberaciones frecuentes, mostrar resultados en seguida, y seguir con el siguiente producto).
Dicho esto, hay una práctica que recomiendo y es que en las reuniones de kick-off de los proyectos, uno tiene la obligación de decirle a los stakeholders cómo será el proceso de desarrollo e implantación, de modo de que todos sepan por cuáles etapas vamos a pasar y porqué (para que no haya sorpresas ni falsas expectativas).
Gracias a vos.
Gracias Pablo por plantear este tema, aunque creo(en mi humilde opinión)que las herramientas están, el problema es el planteamiento de los desarrolladores y el jefe de proyecto para llevar a cabo las soluciones. Tenemos la toma de requerimientos y todo lo que conlleva(Para mi, el punto más importante), los ciclos de vida, los modelos y muchos más. El tema de la gestión proyectos especificamente el área de salud, es la comunicación y el mal uso de las herramientas existentes. En realidad hay tantos factores que hacen que los proyectos no cumplen con las espectativas o que no realizan el verdadero cometido. Saludos!
ResponderEliminarGracias por comentar Victor.
ResponderEliminarEl punto creo que es: hay herramientas, pero ninguna "garantiza el éxito en todos los contextos".
Mi experiencia es que uno debe adaptar las herramientas para cada proyecto y para cada cliente. Cada hospital es un mundo, y lo que aplica a uno rara vez aplica a otro tal cual (incluso el software!).
Existen proyectos de software que han sido éxito en ciertos hospitales y fracasos rotundos en otros.
Lo otro que les recomiendo es esta discusión en linkedin: "Top Ten reasons why EMR/EHR implementations are failing" http://www.linkedin.com/groupAnswers?viewQuestionAndAnswers=&discussionID=10073908&gid=93115&trk=EML_anet_mc_pst_ttle
Saludos,
Pablo.
Hola Pablo, pensando un poco, y reduciendo las ideas de porque los proyectos en Informatizacion tienen poco exito, creo que todo apunta a una sola cosa, las amenzas internas, dentro de las cuales he podido identificar:
ResponderEliminar1º El rechazo al cambio.
2º La existencia de multiples "sistemas informaticos propietarios", que han funcionado por mucho tiempo en las distintas unidades, que componen un Hospital, las cuales tienen muchas falencias en cuanto arquitectura y funcionamiento (y nadie quiere repararlas).
3º La falta de incentivo del personal (profesional, tecnico y administrativo), para aprender nuevas herramientas, ya que siendo francos, muchas veces las capacitaciones internas a veces, requieren ausentarse momentaneamente del lugar del trabajo, y nadie te reemplaza o por otra parte, aunque las capacitaciones sean externas y gratuitas, es un % muy bajo de personas, las que pueden o quieren salir y ocupar su tiempo libre en aprender nuevas herramientas, si saben que no les pagaran por ello (al menos aca en Chile, mas que una tendencia, es un hecho).
Me gustaría saber si Uds. han podido o han encontrado maneras de como poder lidiar con estas amenzas, y que tecnicas o estrategias, les han funcionado.
Gracias y saludos,
Erick H.
Hola Erick,
ResponderEliminarEs muy acertado lo que dices, y si miras el link en mi comentario anterior vas a encontrar una discusión con más de 2000 respuestas sobre porqué falla la informatización en salud.
Sobre lo que planteas, en el estudio de las organizaciones hay algo llamado la "zona de confort", que sería un estado personal estable alcanzado luego de cierto tiempo de trabajo. El problema que nos encontramos en las instituciones sanitarias es que todos sus miembros parecen estar en esta zona, y muy pocos desean salir de ella para mejorar. De ahí viene la resistencia.
Link interesante: http://www.squidoo.com/maslowrevisited
El tercer punto que mencionas es un patrón muy común, y el problema empieza con los puntos "El proyecto debería ser solo un grano de arena" y "Contraparte es algo más que once letras" y "el proyecto médico". Por un lado: debemos sumergirnos en la estrategia organizacional, y tener de antemano el apoyo de los tomadores de decisión. Teniendo ese apoyo claro frente a todos los miembros de la organización, el camino del cambio será más sencillo. Por otro lado, uno como gestor debe tratar de que las personas se adueñen del proyecto, que sientas que es suyo y que su éxito o fracaso será un éxito o fracaso para ellos.
Nosotros debemos resolver algunos problemas, pero no todos, y debemos tener una puerta para tocar en el caso de que surjan problemas que no podemos resolver.
Un consejo en general: comenzar los procesos de informatización con el personal de enfermería. Las y los enfermeros son muy buenos receptores de nuevas y mejores formas de trabajar, y tienen una gran orientación al registro, por lo que será un público con menos resistencia y con el que se podrá trabajar más y más rápido que con los médicos en general. Además son una fuerza de arrastre y contagio dentro de la organización: la enfermera termina enseñando al médico o solicitándole que registre información en los sistemas informáticos.
Saludos,
Pablo.