Recientemente me di cuenta de que he estado liderando proyectos de desarrollo de productos durante más de un cuarto de siglo, con muchos años más de experiencia en diseño de productos además de eso.

Durante este tiempo, he recopilado una lista de consejos de gestión de proyectos que me parecen cada vez más válidos a medida que pasa el tiempo.

Mi experiencia se ha centrado principalmente en el desarrollo de iteraciones de prototipos de dispositivos médicos y otros productos. Considere este contexto en las siguientes sugerencias.

Diviértete

Creo que un equipo de proyecto es más efectivo cuando se divierten. Para algunos, esto puede sonar frívolo, pero no subestimes lo productivo que puede ser un equipo cuando realmente disfrutan de su trabajo. Es más probable que se consoliden y que entreguen esas ideas realmente geniales. Cuando presento un proyecto a un nuevo miembro del equipo, trato de encender una chispa de interés y curiosidad, entre todos los demás detalles mundanos. Me imagino que los miembros del equipo que están asignados a múltiples proyectos tenderán a concentrar su energía en los divertidos. He notado, por ejemplo, que realmente empiezo a tener tracción en un proyecto cuando estoy entusiasmado con él. ¡Supongo que esto es cierto para otros también!

Nutrir esta cultura en primer lugar, y luego no matarla por error, es a menudo un desafío.

Visualizar Listo

Me doy cuenta de que estoy constantemente tratando de averiguar cómo se ve hecho, tanto para determinar qué es lo que mi equipo realmente está tratando de lograr como para qué es lo que realmente necesita el patrocinador del proyecto. Esto a menudo es un proceso iterativo, primero para entrar en el estadio de béisbol correcto y luego para refinarlo.

Por alguna razón, nuestro presupuesto generalmente se determina antes de que tengamos una idea muy clara de lo que se ve hecho. Eso hace que sea muy importante perfeccionar y socializar los detalles rápidamente para garantizar que todos trabajemos de manera eficiente en la dirección correcta. Esto puede ser un poco extraño para las personas nuevas en esta estrategia, pero de alguna manera parece funcionar en su mayoría.

Una gran oportunidad para el éxito del proyecto a menudo está disponible por cambios tardíos en la definición de hecho. Por eso, siempre estoy especulando sobre nuevas definiciones, tanto con el equipo como con el patrocinador del proyecto. Es muy posible que haya una gran ganancia allí en alguna parte, esperando ser descubierta: terminar más rápido, reducir el riesgo, alcanzar el presupuesto, lograr un mejor rendimiento.

Confía en tu equipo

Sospecho que todos hemos trabajado en proyectos en los que el PM se ve presionado a tomar decisiones que hacen que el trabajo del equipo sea realmente desafiante. Por lo general, lo que sucede en estas circunstancias es que algunos miembros del equipo expresarán sus preocupaciones. Inicialmente, estas preocupaciones son corazonadas, difíciles de corroborar. A medida que la situación se vuelve más difícil, todo el equipo se desilusiona y la alegría se evapora.

Creo que el trabajo del PM es escuchar cuando el equipo expresa sus preocupaciones y notar cuando su optimismo se ve afectado. Incluso sin pruebas suficientes, el primer ministro tiene que tratarlo con seriedad y hacer retroceder al equipo. Si el equipo no siente que el PM los cubra, entonces, una vez más, la alegría se resiente.

No azotes a tu equipo

Veo este comportamiento muy a menudo. Alguien llega tarde a una tarea y el PM lo llama, generalmente en una reunión de equipo. Desafortunadamente, he estado en ambos extremos de esto varias veces y he aprendido que nunca ayuda. El único resultado que he notado es que un miembro del equipo ahora se siente mal.

Esto es realmente complicado como PM; necesita descubrir cómo volver a encarrilar el proyecto, sin embargo, es muy fácil inculcar la idea de que esta persona tiene un rendimiento inferior y decepciona al equipo. Del mismo modo, el resto del equipo ve que todo se desarrolla y eso los preocupa.

Agradecería cualquier consejo sobre cómo solucionar este tipo de problema. Mi enfoque es comprometerme con el individuo y centrarme en su enfoque de diseño, y particularmente en lo que se ve hecho para esa tarea. Si la tarea es realmente larga en cuanto a tiempo o presupuesto, evalúo si es posible un cambio significativo en la arquitectura que restablecerá las cosas. Involucrar a un grupo más amplio puede ser útil, pero esto también puede ser complicado, asegurando que todos piensen positivamente sobre las posibles soluciones y evitando cualquier cosa que pueda interpretarse (o malinterpretarse) como culpa.

No se concentre demasiado en el Gantt

Un truco que aprendí sobre los diagramas de Gantt es hacerlos tan detallados como los hitos clave del proyecto. Profundizar en la interdependencia temporal de las tareas individuales es un trabajo ingrato que no crea mucho valor.

En su mayoría, hay tareas e hitos clave de alto nivel que deben rastrearse en un cronograma, como cuando se completa el diseño de un prototipo, cuando se piden las piezas, cuando la construcción de un primer prototipo está lista para la prueba o cuando los prototipos están completos.

Encuentro que la única razón para explorar tareas con mayor granularidad es rastrear el proceso de quemado del proyecto. Esto se logra efectivamente con una lista, en la que a cada elemento se le asigna el esfuerzo estimado. A medida que se completan las tareas, se libera ese esfuerzo y la estimación total hasta la finalización disminuye. El quemado de las tareas de alto nivel puede informar cómo estamos rastreando los grandes hitos que a todos les importan.

Un enfoque relacionado que uso es solo dividir las tareas en subtareas cuando estamos más cerca de hacer ese trabajo. La única razón para subdividir tareas es mejorar la granularidad de nuestro trabajo pendiente y actuar como un recordatorio para no olvidar cosas particulares. A menudo, es mejor esperar hasta que el trabajo esté frente a nosotros antes de perdernos en los detalles.

El horario siempre pierde

Es bastante común que la gente hable sobre las restricciones triples de PM (presupuesto, alcance y cronograma) y cuál es la más importante en un proyecto.

No importa lo que digan los demás, el presupuesto parece ganar siempre. Cuando se acaba el dinero, los engranajes dejan de girar. Un proyecto en el que el dinero realmente no es una preocupación casi nunca sucede.

Si el presupuesto es el rey, entonces el alcance le sigue de cerca. Sí, a menudo hay flexibilidad en lo bueno que debe ser un prototipo, pero siempre se requiere un nivel mínimo de preparación. Si aún no lo has logrado, entonces no has terminado. Y no trabajes al mínimo aquí, ¡esa nunca es una buena estrategia!

Entonces, si nuestro presupuesto es limitado y en su mayoría inamovible y hay un nivel de trabajo que debe lograrse, entonces el cronograma debe ser el último.

He trabajado en muchos proyectos que trataron de forzar un cronograma y siempre se vuelven amargos. El problema es que si no has terminado, no has terminado. Centrarse constantemente en llegar tarde genera todo tipo de comportamiento improductivo: malas decisiones de diseño, moral reducida y más errores. Puf va la alegría en el proyecto.

No estoy diciendo aquí que todos los proyectos se retrasarán, solo que, según mi experiencia, cuando las cosas se ponen complicadas, el cronograma siempre saca la paja corta.

Estimar con datos

Si está estimando un proyecto, un enfoque de arriba hacia abajo basado en datos históricos funciona mejor. Un enfoque de abajo hacia arriba parece impresionante y transmite una apariencia de precisión, pero a menudo está inflado y es difícil de revisar para verificar la precisión. En cambio, el uso de puntos de datos de rendimiento reales para proyectos similares, idealmente para su equipo en particular, brinda una estimación de esfuerzo más confiable.

En mi opinión, el propósito de estimar es establecer la cantidad de efectivo que necesitará para completar un proyecto, no mucho más. Más tarde, querrá prepararse para monitorear y controlar el progreso del proyecto. Eso requiere un tipo diferente de descomposición y análisis del proyecto y, a menudo, se adapta bien a un enfoque de abajo hacia arriba.

Por supuesto, puede ser útil hacer ambas cosas; eventualmente necesitará hacerlo. Entonces puede encontrarse en el medio y generar confianza en sus números.

La clave es utilizar datos históricos siempre que sea posible. De esa manera, comenzará con números que han sido probados. El siguiente paso es descubrir cómo repetir esos resultados en el nuevo proyecto.

Equipos pequeños

Según mi experiencia, lo único para lo que sirve un gran equipo es para quemar el presupuesto muy rápido. Si desea que su equipo vaya más rápido y los miembros de su equipo no están trabajando a tiempo completo en su proyecto, lo mejor que puede hacer es obtener más de su tiempo, no obtener más personas. Si no puede obtener más de su tiempo, es mejor que vaya más despacio. La alternativa es quemar más presupuesto por falta de eficiencia.

Sí, necesita personas con toda la experiencia requerida. Cuanto más pueda consolidar esa experiencia en un pequeño número de personas multifuncionales, mejor. Diría que aún es mejor incluso si no son superexpertos en algunas de esas áreas.

busca guau

Es bastante común que durante un proyecto, a ti o a uno de tus compañeros de equipo se les ocurra una idea que suene realmente genial. Puede ser llevar los objetivos de diseño un poco más lejos, puede ser un nuevo giro o una oportunidad que hará que el proyecto se desarrolle sin problemas.

En esa situación, siempre le doy alguna consideración. Primero pregunto si podemos lograr esta nueva idea dentro del presupuesto y el tiempo disponible. A menudo, especialmente al principio del proyecto, estas ideas vienen gratis. Si la nueva idea cae dentro del mandato de diseño, entonces diría que lo haga. Si está más allá del mandato, planee discutirlo con el patrocinador del proyecto. Si hay un riesgo de proyecto asociado con él (casi siempre lo hay), entonces dale mucha consideración. Piense en formas de mitigar ese riesgo. Piense en la gravedad del proyecto si el riesgo se hace realidad. Tal vez considere diseñar en un Plan B o establecer un experimento de eliminación de riesgos.

Si la idea surge más adelante en el proyecto, igual considérala. Después de pensarlo un poco, es posible que no fuerce una ruptura total, o tal vez pueda implementarse de manera limitada. Tal vez realmente sea tan revolucionario que valga la pena reiniciarlo por completo.

Estar atento a estas oportunidades y hacer todo lo posible para fomentarlas es una excelente manera de impulsar el espíritu de equipo e impresionar a los clientes.

Lo mejor es encontrar una manera de hacerlo, dentro del presupuesto y el mandato existentes. Convertir cada oportunidad como esta en una renegociación del alcance y el presupuesto tiende a matar la alegría.

Nunca es demasiado tarde para deshacerse de una mala idea

Al igual que saltar sobre las buenas ideas cuando se descubren, creo que también es la elección correcta saltar sobre las malas tan pronto como se identifican. Un ejemplo podría ser cuando se descubre que una elección arquitectónica anterior es incorrecta. Cuando se encuentra temprano, no es gran cosa. A veces, sin embargo, aparecen más tarde en un proyecto y eso dificulta las cosas. Sin embargo, estos problemas seguirán empeorando. Antes de que te des cuenta, es un Ave María completo con capas de tiritas y se vuelve más y más difícil de corregir.

Constantemente tenemos que tomar decisiones arquitectónicas con información limitada. Algunos de estos resultan ser geniales, otros no tanto. Una vez que reconozcamos que no nos dirigimos a la grandeza, debemos corregir rápidamente. Si esto significa un poco de reinicio del proyecto, entonces hágales saber a todos que es necesario y corrija el curso. Esperar que las cosas mejoren de alguna manera cuando sabes que están en el camino equivocado no es una gran estrategia para el éxito.

No tome decisiones demasiado pronto

A menudo es reconfortante tomar decisiones arquitectónicas decisivas al principio de un proyecto. Se siente como si realmente estuviéramos perfeccionando nuestra trayectoria y creemos que la mayor claridad en el alcance aumentará nuestras posibilidades de éxito. En mi experiencia, posponer las decisiones hasta que sean absolutamente necesarias puede ser mejor.

No es necesario que todas las decisiones se tomen de inmediato para que un equipo sea efectivo. Algunas decisiones naturalmente estarán mejor informadas a medida que avanzan otras tareas. Esas son las clases de elecciones que vale la pena evitar.

Todavía podemos tomar nota de nuestras opciones, de la resolución disponible, pero esperar a elegir definitivamente hasta que realmente debamos hacerlo. No me refiero a retrasar el proyecto; Me refiero a no tomar una decisión hasta que esté en el punto en el que debe avanzar por una bifurcación u otra. A medida que se acerca a la bifurcación, puede pensar en la información que realmente desea tener cuando llegue allí. Esto podría llevarlo a cambiar el orden de algunas tareas para generar esta garantía; tal vez haya algunas actividades nuevas que ayuden con la decisión.

El problema es que una vez que hemos tomado una decisión, comenzamos a combinar decisiones sobre ella. En poco tiempo, la capacidad de deshacerlo se vuelve demasiado costosa.

Los equipos eficientes a menudo tienen recursos limitados

Encuentro que cuando un equipo funciona con la máxima eficiencia, siempre tiene un poco de recursos limitados. Presumiblemente, este es el resultado de algunas de mis otras reglas generales: mantener el equipo pequeño, el presupuesto y el alcance son lo primero, etc.

El truco aquí es acostumbrarse. Sí, su proyecto tendrá un cuello de botella de vez en cuando. Sí, las tareas se deslizarán si otras se exceden. Pensaría con mucho cuidado antes de considerar contratar a otro miembro del equipo, especialmente si solo necesita una fracción de su tiempo.

Espero que hayas encontrado algunas pepitas útiles en estos consejos. Tal vez algunos de ellos resonaron con sus experiencias, tal vez algunos sugieran un giro diferente y posiblemente útil en la gestión de iteraciones de prototipos.

Imagen: StarFish Medical

Kenneth MacCallum, Peng, es un físico ingeniero principal en StarFish Medical. El trabaja en Innovación en dispositivos médicos para una variedad de áreas, incluidas las aplicaciones de ultrasonido. A Kenneth le encantaría escuchar a los lectores sobre sus diseños y experiencias de referencia.



• Distribución de relaciones públicas y contenido potenciado por SEO. Consiga amplificado hoy.
• Platoblockchain. Inteligencia del Metaverso Web3. Conocimiento amplificado. Accede Aquí.
• Fuente: https://starfishmedical.com/blog/top-lessons-in-project-management-of-medical-device-development/