Los sombreros de un PM

Artículo escrito por Mauricio Aranda Solares

Cuando nos enfrentamos con la gestión de proyectos, los PMs se encuentran con la realidad de que no solo son PM, sino también deben de ocupar "sombreros" de otros roles con el principal objetivo de sacar adelante de forma exitosa el o los proyectos que tenga a su cargo. Ya en una entrada anterior he hablado sobre ésto. Ahora, me gustaría detallar un poco en que consisten los tres roles principales que detecto en un PM: Gerente-Líder Técnico-Facilitador. Para ello ocuparé la analogía de los sombreros, que prefiero nombrar: "Los sombreros de un PM".

Desde mi perspectiva, cuando vamos a gestionar un proyecto es importante tener a la mano tres sombreros: uno de líder, otro de gerente y uno mas de facilitador. Esto simplifica la toma de decisiones en todo momento.

Imaginemos que tenemos un sombrero color verde, otro sombrero color blanco y un sombrero color rojo (sí lo sé, como la bandera de México). Bueno, ahora, el sombrero verde represente a un líder técnico, el blanco al facilitador y el rojo al gerente. Pero, ¿cuáles serían sus responsabilidades?....

1. Cuando el PM se ponga el sombrero verde... éste tiene la responsabilidad de focalizar esfuerzos en hacer que el equipo haga muy bien su trabajo; que cada integrante participe con sus respectivas habilidades técnicas que lo hace fuerte; se debe de concentrar en el qué y el por qué; establecer y definir tareas y metas objetivas; asegurarse que todos terminen sus tareas en tiempo y forma; inspirar, motivar e incitar a ser innovadores y creativos con cada problema que se presente. 
2. Cuando el PM se ponga el sombrero blanco... éste tiene la responsabilidad de enfocarse en ayudar a su equipo a obtener los resultados deseados; negociar con el cliente y mostrarle la mejor solución acorde al tiempo, esfuerzo y coste contemplados; ayudar a su equipo a concentrarse y bloquear todo problema o pleitos externo que solo contamine o afecte el desempeño de éste; ser un puente entre el cliente y el proveedor para alinear los objetivos del negocio con el proyecto; asegurar el compromiso tanto del cliente como del proveedor; gestionar riesgos antes de que se conviertan en un problema; eliminar barreras u obstáculos que interrumpan en el flujo de la solución. 
3. Cuando el PM se ponga el sombrero rojo... éste tiene la responsabilidad de obtener el mejor producto en tiempo, coste y calidad; concentrarse en el cómo; establecer metas, planes, objetivos y estrategias; dar seguimiento a cada tarea en un macropanorama hasta el cierre de las mismas; ejecutar, controlar, gestionar y resolver los problemas que se presenten; presentar reportes a sus respectivos directores o jefes inmediatos.

Suena sencillo, y realmente lo es... lo complicado aquí es tener la disciplina de hacerlo y estar consciente qué sombrero debemos de usar en cada situación. Algo indispensable que debe de tener bien presente cada PM es:

• Sé quien soy y lo que sé hacer: eso se traduce en confianza en mi mismo.
• Saber cuál es el objetivo del proyecto en el que me encuentro: eso da lugar a que de una u otra manera buscará la solución o la forma para obtener lo que se necesita.
• Los aspectos físicos son importantes: que no se mal interprete, pero una buena imagen empieza desde los zapatos, la forma de hablar y el lenguaje corporal que usamos.
• El temple se debe de mantener: las emociones se hacen a un lado... los nervios, la ira, la tristeza y demás... no aportan al temple, ni mucho menos a la toma de decisiones, hay que controlarlas y dejarlas a un lado.

10 tips para un PM con proyectos de Desarrollo de Software

Artículo escrito por Mauricio Aranda Solares

Día con día nos topamos con muchos proyectos que presentan una gestión del proyecto deficiente o incluso mala, dejando mucho de que hablar de los PM que se encargan de cada proyecto. La duda que surge es: ¿realmente todo es culpa del PM?.... 

Además de las tantas buenas prácticas que existen hoy en día para la administración o gestión de proyectos, es todavía más importante USAR EL SENTIDO COMÚN, LA EXPERIENCIA, LA INTUICIÓN y NUESTRO PROPIO CRITERIO en cualquier tomar de decisiones. Muchos de los PM que he conocido dudan de lo que van decir o van hacer, y ésto, en gran medida, se debe a la falta de conocimiento ya sea: del proyecto, de la empresa, del equipo o incluso de sus propias herramientas y/o habilidades con las que cuenta. En mi experiencia (aclaro que los proyectos que llevo son exclusivos del área de TI, pero no por ello puedo pensar que el siguiente listado son fácilmente alcanzables en cualquier otra área), para decidir qué decisión se debe de tomar para solucionar o salir de n situación convienen aplicar los siguientes tips:

1. Conocer los procesos internos del área: Esto implica conocer (o en todo caso definir) un macroproceso del área, proceso para la toma de requerimiento, proceso de creación de prototipos (demos), proceso de modelado arquitectónico, proceso para el desarrollo de la solución, proceso para la ejecución de pruebas, proceso de generación de reportes de servicio, proceso para liberar la solución en ambientes QA o Productivo, proceso de atención al cliente, proceso de solicitud de recursos financieros, proceso de solicitud de recursos técnicos y proceso de solicitud de recursos humanos. 
2. Planificar tareas: Es importante delimitar los bordes (tiempos principalmente) del proyecto para crear una lista priorizada de entregables que serán liberados (en mi caso, regularmente son fases de tipo iterativa) al cliente. También hay que considerar planes comprensivos, realistas y bien aterrizados con TODO el equipo de trabajo, especialmente con los líderes técnicos que al final del día son los que sufren mas con esas fechas definidas que se han dado al cliente solo con el único objetivo de "quedar bien". Considerar que cada entregable del proyecto y tiene riesgos involucrados, por lo tanto es importante ir elaborando un listado de riesgos que pudieran obstruir, restringir o detener la entrega parcial o total del producto.
3. Priorizar tareas: Generar y priorizar la lista de tareas (aunque esta sea muy general) es muy importante al momento de valorar correctamente los tiempos del proyecto, sin embargo, esta lista es todavía mas importante conocerla al momento de tener reuniones o mesas de trabajo con el cliente. ¿Cómo podemos tener una lista de tareas más realista?... yo veo una sola respuesta muy sencilla: Contar con un equipo de negocio que se encargue de levantar y valorar adecuadamente todos los requerimientos (funcionales y no funcionales), así como las reglas de negocio y los objetivos de cada entregable ALINEADOS al contrato definido entre proveedor y el cliente. Si su empresa cuenta con un equipo de negocio que simplemente NO hace bien su trabajo, lo mejor será enviar un técnico (junto con el equipo de negocio) que cuente con habilidades verbales, sentido común y lógica a todas las sesiones y reuniones de trabajo con los clientes desde un inicio (esto suena a gasta el tiempo de un recurso valioso... lo sé, lo sé... pero créame que le ahorra muchos cambios de requerimientos en un futuro y muchas quejas por parte del cliente, y por ende, le ahorrará dinero). El enviar a un recurso técnico junto con el equipo de negocio a las reuniones con cliente, ayudará en aclaración de dudas, aterrizará las ideas del cliente y evaluará mas objetivamente las expectativas de ambas partes. ¿Por qué ésto debe de importarle al PM? porque si el PM está consciente de la importancia de lo anteriormente dicho, entonces no será necesario supervisar hasta el último detalle de las reuniones y las tareas definidas (ésto no quiere decir que descuide su trabajo) y con ello podrá enfocarse mayormente a la negociación con el cliente de temas realmente importantes como lo son el tiempo y el dinero. Mi consejo es: toda tarea PRE-definida entre cliente, equipo de negocio y técnicos debería de ser reportada al PM y al Director de Desarrollo para que éstos conozcan claramente lo que se ha bajado en las reuniones de trabajo y posteriormente, si aplican, acordarse por escrito o correo la realización de las mismas. Recuerden que en una reunión de trabajo con cliente NO debemos de comprometernos en tiempos o tareas sin antes contar con el VoBo del PM y del Director de Desarrollo. Recomiendo siempre generar una minuta y/o hoja de alcances firmada por ambas partes (proveedor y cliente) donde se escriba lo acordado entre los participantes. 
4. Seleccionar acertivamente los recursos humanos: Hace un momento toqué el tema del equipo de negocio que NO hace bien su trabajo, es triste pero cierto. En muchas empresas, la selección del personal se hace con el compañerismo, pagar favores, entrevistas mediocres o simplemente "sale mas barato". OJO PMs... aunque nada de esto pudiera ser su culpa, es una triste y pesada realidad lo cual afecta y baja la calidad del producto final. Al seleccionar al personal para nuestro proyecto hay que contar con conocimientos del área, lectura en frío del lenguaje corporal, y una buena dosis de intuición. Los nuevos recursos deberían de contar con conocimientos firmes de lo que realmente se necesita, nada de "pues mas o menos parece que le sabe".... por otro lado, si la persona cuenta con muchas ganas de aprender y una muy buena actitud laboral y personal, ésto (para mi) cuenta mucho más que las habilidades técnicas. Ambas cosas son factores críticos en la selección de recursos humanos, y como PMs deberíamos estar involucrados en éstas entrevistas para conocer al posible futuro candidato. El mismo tema que el anterior.... seguramente pensarán que es perdida de tiempo, pero mas vale conocer lo que entrará al equipo que batallar con un parásito que solo consuma tiempo y esfuerzo del resto de los integrantes. Si por el contrario, ya existe un equipo y cuenta con buenos y malos elementos, bueno, aquí el tip es adaptarnos a lo que tenemos, aprender de ellos y motivarles... saber en qué se sienten a gusto trabajando y con ésto saber a qué tarea o proyecto deberán de ser asignados. Normalmente cada recurso trabajará más de 40 hrs a la semana, lo cual es muy pesado para la gente que realmente ésta haciendo su "chamba", por eso lo mejor es encontrarnos en un ambiente donde (sino es que todos), la mayoría se encuentren contentos con lo que hacen, que vean al grupo como una sola unidad, una segunda familia por todo ese tiempo que tenemos que compartir, apoyarse e incluso salir a comer juntos para generar un ambiente armonioso en la mayor medida posible. En la práctica, es casi imposible pagarles horas extras, por lo que debemos de buscar formas de hacerlos sentir muy contentos con lo que hacen, incluso hacerles sentir que el tiempo "se va volando". 
5. Estimar tiempos realistas y con sentido común: Estimar costes y tiempo son la parte más delicada y difícil de una planificación. Hay que cuidar los sobre-costes, analizar las clausulas del contrato y los acuerdos de trabajo (SoW), principalmente aquellas en donde entran deducciones o multas o penalizaciones por incumplimientos o retardos de n entregable. En la práctica, no he visto quién use seriamente alguna metodología para las estimaciones de costos y tiempos. La mayoría de los PM solo sacan cálculos imaginarios y poco realistas. Pero no creo que sea del todo culpa de ellos... lamentablemente, en cada proyecto se contratan nuevos PMs (como si éstos fueran magos que conocen todo el background de un proyecto) y para colmo lo hacen cuando ya ha arrancado el proyecto. Los tiempos y costos regularmente llevan un "colchón" que según se cuenta, servirá bastante, sin embargo en muchas ocasiones, los que vendieron el proyecto y los que hicieron estas planificaciones son personas totalmente distintas, ya ni se diga de los que administrarán o le darán seguimiento al proyecto, lo cual dificulta mas aún la tarea de estimaciones. Lo que recomiendo en estos casos es, desde que vendemos el proyecto, llevar a una persona con habilidades técnicas que cuente con la experiencia suficiente para aterrizar, desde un inicio, un tiempo y coste mas realista. Vender con el apoyo del área técnica, y entre ambas áreas (ventas e ingeniería por ejemplo), realizar una estimación bottom-up o alguna otra técnica de métodos cuantitativos de administración de proyectos que aterrice mejor los tiempos y costos. En este tipo de estimaciones es super importante que se consideren las variaciones e incertidumbres que pudieran presentarse (Risk Management). Cuanto mas grande es el proyecto mas complicado se vuelve la estimación de costos, tiempo y recursos, y con mayor razón deberíamos de apoyarnos en nuestros compañeros técnicos. Otra recomendación es desarrollar proyectos con entregas iterativas, mitiga los riesgos en cada fase e ir estimando mejores alcances en cada entregable, aunque aquí el coste y el tiempo de distribución del proyecto también serán variados y por ende las ganancias pueden ser las no esperadas.
6. Promover las auditorias internas: No esperemos a que una institución externa llegue y audite a nuestros clientes, ésto siempre se me ha hecho poco ético. Bien sabemos que no hay sistema perfecto y no hay producto que se entregue en la primer fecha definida. Por mucho que contemos con miles de certificaciones ISO en nuestra empresa, ésto no nos quita el error por factor humano (como decimos los de sistemas: error de capa 8). Por lo tanto, lo mas sano y ético sería contar un uno o dos personas de la misma empresa que fungen como auditores internos y conozcan las "cosas" que se van a auditar con base en los contratos establecidos con los clientes.  Desde ese punto, hemos ganado mucha ventaja ya que nos asegura mayor calidad en lo que estamos haciendo. Es muy importante evaluar la salud del proyecto y del producto, preferiblemente en cada fase o entregable, especialmente si estas cuentan con el apoyo del área de pruebas y aseguramiento de la calidad. Dentro de las cosas que hay que auditar son: el estado del producto, que cumpla con el flujo o proceso definido por el cliente, la seguridad del producto, la atención o servicio al cliente final, entre otros que se les ocurra. Como PM es importante medir el costo vs el tiempo estimado, pero también, asegurar que lo que estamos entregando cumple con lo establecido entre el cliente y el proveedor. El PM deberá de contar con criterios de medición tanto de calidad como de productividad y eficiencia para saber dónde estamos parados actualmente, y el qué y el cómo debemos de mejorar nuestro producto. Se puede medir el control del tiempo y tareas; el control del alcance y cambios; el control de rendimiento del proyecto y del equipo, el control de los costos y valor agregado y el control de la calidad, bueno, es solo poniendo un ejemplo, el punto es auditar lo mas que podamos auditar. Al final del día, con todo lo anterior dicho, podemos generar reportes, proyecciones, nuevos alcances, implementar medidas correctivas o preventivas y reparar los defectos.
7. Controlar los cambios solicitados por el cliente: Usar herramientas automáticas de RM (Requirement Management) ayuda bastante, sin embargo, ¿qué hacer cuando tenemos que lidiar con un cliente que no sabe lo que quiere?. Contar con procesos que indiquen el procedimiento adecuado para solicitar un cambio y el nuevo alcance que éste tendrá, así como el método y persona para su aprobación es la mejor opción y de gran ayuda para un PM y un líder técnico. Sin embargo, en la mayoría de las veces no se cuenta con un proceso que nos día santo y seña de lo que debemos de hacer ante tal escenario. Aquí la idea es conoce muy claramente el alcance (preferentemente leer con mucho detenimiento el contrato establecido entre cliente y proveedor) inicial del proyecto, con ésto se tendrá la idea del qué si puede y del qué no puede solicitar el cliente, y tener en cuenta que ésto nos convertirá muy probablemente en el enemigo o barrera número uno de cliente. La cuestión aquí es que aunque el cliente firmara el contrato, posiblemente no se acuerda o no tiene ni idea de lo que decía en dicho documento, por lo tanto, la administración de cambios se vuelve una lucha entre proteger la viabilidad de la definición del proyecto ya definidas y aprobadas (para evitar una futura multa o fallo al momento de una auditoria inesperada) y tener contento al cliente. Recuerden siempre: es muy indispensable que la solicitud del cambio se haga de manera formal, bajo un escrito. Cada cambio, de aplicar, deberá de verse reflejado en los requerimientos funcionales o no funcionales, en las reglas de negocio, en flujos alternos, los mock-ups e incluso, en la definición de la arquitectura. Ésto evitará muchas confusión futura y malos entendidos. Es cierto que es imposible anticipar todas las solicitudes y requerimientos durante la fase de análisis, sin embargo, cuando aplique una de estas solicitudes deberá aprobarse con base en el valor e impacto en el proyecto en términos de costo, tiempo y calidad.
8. Definir las incertidumbre y probabilidades: No soy un experto en este tema, sin embargo, es claro que todas las posibles contingencias deberán de ser bien definidas y manejadas para evitar efectos colaterales. Las técnicas que pueden usarse son: MonteCarlo, Varianza de la media, o simplemente un porcentaje del total de costo o tiempo adicional para no afectar la calidad y tiempo del producto. Lo mas completo seria definir todas estas incertidumbres dentro de una plantilla de RiskProject, o si prefiere algo mas sencillo, vaciar todos los riesgo en una plantilla del Microsoft Project.
9. Contratar servicios de outsourcing: Muchas veces, cuando el proyecto es muy grande son validas la adquisición de servicios externos, esto con el objetivo de mantener altos niveles de calidad (especialmente para aquellas empresas que están en algún nivel de madurez CMMI). Sub-contratar una empresa podría, en algunos casos, ayudar a mantener flujos o procesos con determinado nivel de calidad que el cliente puede demandar del proveedor. Aquí, el papel del PM es de suma relevancia, ya que debe de realizar esfuerzos enormes para mejorar brindar servicios y productos que cumplan con lo establecido en sus procesos que serán auditables. OJO, porque esto no quiere decir que siempre será el mejor producto o servicio para el cliente. Por poner un ejemplo, muchas veces el cliente quiere un desarrollo ágil bien documentado y además exige al proveedor contar con certificaciones de calidad que garanticen un producto digno de toda organización con renombre internacional. Sin embargo, esto es poco creíble, ya que entre mas niveles de madurez cuente la empresa mas documentación y procesos burocráticos podrían presentarse, afectando la calidad y el tiempo de entrega del producto o servicio. Y eso no es un tema de CMMI, sino del malentendido que se tiene sobre lo qué implica o es n nivel de madurez. Por lo antes mencionado, antes de subcontratar o no a otra empresa les recomiendo que se evalúen el por qué van a subcontratar otro servicio y si realmente vale la pena el gasto sustancial de dinero y tiempo que esto implica. Para esta evaluación puede hacerse las siguientes preguntas: ¿el cliente nos pide que estemos certificados en alguna norma de calidad o nivel de madurez organizacional?, ¿contamos con los recursos técnicos o humanos para desarrollar el producto?, ¿cuándo fue la última vez que creamos o trabajamos en un producto o servicio similar y cómo lo hicimos?, ¿existe documentación relacionada al producto o servicio que queremos crear?, ¿qué áreas son las más fuertes y cuáles son las más débiles?, ¿cuáles son sus planes de mejora continua que se tienen planeados para el proyecto en general?, ¿con qué otros clientes estamos trabajando?. Hay que considera estas preguntas como base y tener cuidado al subcontratar una empresa para realizar cierta tarea ya que esto no quiere decir ni asegura que nos libraremos de todos los problemas. Hay que desarrollar relaciones y lazos fuertes con nuestros proveedores, monitorear constantemente cada una de las tareas y el tiempo en que se ejecutan, firmar compromisos simultáneos, generar una planificación conjunta, ser claros en caso de que se presente una crisis o falta de cumplimiento de los contratos, revisar la estabilidad de los proveedores, entre otros. Recuerden, muchas veces subcontratar es la peor decisión si no conocemos o tenemos buenas referencias de esa empresa.  
10. Mas que un PM: El rol del PM siempre deja mucho de que hablar, incluso debo de admitir que desde mi perspectiva, el PM debe de ser algo así como un Gerente-LíderTécnico-Facilitador. Todos los grupos van madurando a lo largo del tiempo y desarrollo nuevos proyecto, y el PM deberá clasificar al o los equipos conforme a sus capacidades técnicas, resolver los conflictos con cliente, resolver los conflictos internos, tomar decisiones en tiempo-costo, eliminar obstáculos, guiar al equipo técnico, escuchar activamente, motivar la participación y trabajo en equipo, dar el ejemplo, conocer el negocio de la empresa de pies a cabeza, generar confianza y estima, demostrar carisma, empatia, respeto y sensibilidad por el grupo de trabajo, entre muchas otras cosas que se espera de él o ella. ¿Es ésto una gran responsabilidad?, ¿conocemos realmente el papel de un PM?, ¿un PM nos asegura de que todos los proyectos están estratégicamente bien alineados a la empresa?, ¿es responsabilidad completa del PM analizar y evaluar cada proyecto?.... Yo creo que NO. Mas bien, esperamos mucho mas de lo que el rol en si es por propia esencia. Es verdad que el PM debe de encargare de la gestión de los proyecto y ello tiene implícitamente muchas otras tareas, donde quizás las mas importantes son prioriza los proyectos y sus respectivas tareas y generar estrategias corporativas alineadas a los intereses de la empresa y al mismo tiempo mantener contento al cliente. Donde de todas las mencionadas anteriormente creo que la mas primordial es la comunicación directa con el cliente y la confección de sus metas y objetivos a seguir para cerrar el proyecto de forma exitosa en tiempo y coste. La Gestión de Proyectos es un trabajo en equipo que debe de darse entre los actores: Director del Àrea-PM-Líderes Técnicos. El PM podría determinar el posible éxito y el impacto que generaría en la empresa y con los clientes x proyecto, sin embargo no es del todo su total responsabilidad. Es importante que un PM hable con la verdad y reconozca los limites del proyecto, en algunas ocasiones es valido cancelar o detener el plan actual y volver a re-plantear una nueva estrategia o implementar mejores prácticas de Project Management Estratégico. Generar un documento con lecciones aprendidas para ser llevadas a proyectos futuros, a los directores y a su equipo de trabajo. Dentro de los factores de éxito estratégico de un PM se encuentran: La utilización de un criterio de claro; el criterio para nuevos cambios en los requerimientos; la habilidad para desarrollar una solución con un equipo reducido o muy grande; la habilidad para alcanzar los objetivos y entregables definidos; la habilidad para entablar una buena relación con los clientes y lidiar con ellos cuando se quejan de algún problema en el producto o en la entrega del servicio; la capacidad de llevar a tiempo y forma un producto o servicio en producción; la capacidad de medir económica y sustancialmente el proyecto en cuestión, dentro de los límites establecidos.

Feedback en la Gestión de Proyectos

Artículo escrito por Mauricio Aranda Solares

Actualmente, la mayoría de los procesos ágiles que utilizamos para la gestión de proyectos o los que se propone implementar en muchos libros o páginas web resultan en más trabajo que el proyecto en si mismo... Si éste es su caso, evidentemente necesitará repensar o simplificar dichos procesos, es decir, NO discutir el proceso sino su usabilidad y practicidad.

Tenemos tantas metodologías y las mejores prácticas del mercado en la web que sería solo una perdida de tiempo reinventar la rueda. Lo mejor es replantearse dichas metodologías y en muchos casos hacer un análisis POSTMORTEM donde: (a) se revisa el trabajo del equipo y de cada uno de los integrantes en el proyecto anterior; (b) se analizan todas las tareas realizadas y no realizadas; (c) se revisa el desempeño y cumplimiento de los objetivos del equipo en cuanto a calidad, tiempos y costos. Para ello podemos plantearnos las siguientes preguntas:

1. ¿Cuál fue el desempeño del líder técnico?
2. ¿Cuál fue el desempeño de cada miembro en términos de trabajo personal y trabajo en equipo?
3. ¿Se cumplió el rol de cada integrante del equipo?
4. ¿Qué personas fueron las más pro-activas?
5. ¿Qué fue lo mas innovador que se hizo en el proyecto y cuál fue el resultado final?
6. ¿Cuáles metas fueron cumplidas y cuáles no?
7. ¿Cuáles fueron los resultados finales del proyecto (incluyendo los resultados buenos y malos)?
8. ¿Cuáles fueron los inconvenientes que impidieron que se cumplieran x ó y metas de calidad?
9. ¿Cómo fue el rendimiento de recursos humanos y financieros comparado con el plan de trabajo?
10. ¿Qué lecciones se pueden aprender del proyecto cerrado?
11. ¿Dónde se encuentran las oportunidades para mejorar en el siguiente proyecto y por qué?
12. ¿Cuáles fueron las tareas con mas problemas y qué se puede hacer para corregirlos en el próximo proyecto?
13. ¿Cuáles fueron las tareas que sí se realizaron en tiempo y forma, y por qué?
14. ¿Qué herramientas para automatizar tareas o procesos se sugieren para el próximo proyecto?
15. ¿Qué procesos se pueden crear o mejorar para el próximo proyecto?
16. ¿Qué recursos humanos se deberían de incluir en el próximo proyecto?
17. ¿Cuáles las incidencias más comunes reportadas por el cliente durante la fase en productivo?
18. ¿Cuáles fueron los riesgos más graves?
19. ¿Cuáles fueron las estrategias más exitosas que solventaron la mayoría de los riesgos?
20. ¿Cuál fue el tiempo máximo de respuesta en una incidencia?

Y así podríamos obtener cientos de preguntas que podríamos presentar en una reunión de feedback, sin embargo, las mencionadas anteriormente (por experiencia propia) nos ayudarán a conocer si la metodología que usamos actualmente cumple con su objetivo o requiere ligeros ajustes o incluso mezclar con alguna otra metodología o estándares que nos permita mejorar día a día. Cada proyecto es una nueva oportunidad para mejorar nuestra forma de trabajo y la calidad de nuestros productos (mejora continua), aprendiendo de las experiencias anteriores y analizando con criterio y sumo cuidado cada una de las prácticas en el ciclo siguiente. Sin embargo... "somos flojos para realizar este tipo de análisis e incluso para plantearse estas sencillas 20 preguntas"... El tiempo o la urgencia no es el pretexto, ya que si nos detuviéramos unas cuantas horas (de 2 a 6 hrs en promedio) en realizar estas preguntas entre todo el equipo o tan solo entre los líderes de proyecto y los líderes técnicos, nos ahorraría mucho mas tiempo, recursos y dinero en cada nuevo proyecto que se presente.

Para arrancar un nuevo proyecto con base en un análisis postmortem es importante:

• Examinar los datos de entrada, de procesamiento y de salida del nuevo proyecto
• Identificar si hay procesos que pueden re-usarse
• Identificar, en la mayor medida posible, cada tarea
• Identificar a los miembros adecuados para cada tarea y para la coordinación del o de los equipos
• Identificar las tareas que podrían tener mayor dificultad, problemas, necesidades o mejoras especiales que no se contemplaron

Para todo lo anterior, el líder de proyecto cuenta con un papel muy importante. Su participación debe de enfocarse principalmente a:

1. Revisar el desempeño de cada uno de sus miembros
2. Revisar requerimientos funcionales, no funcionales y reglas de negocio
3. Implementar estrategias o metodologías que sean pro de la calidad del proyecto, acorde también a las políticas del cliente.
4. Tener una planificación clara para todo el equipo, aunque no se presenten todas las tareas, si se debe de contar con los tiempos bien definidos
5. Asignar metas más alcanzables y realistas a cada miembro del equipo acorde a sus capacidades técnicas
6. Si detecta que uno de los miembros del equipo tiene mas potencial, darle nuevos retos y oportunidades para apoyarlo a crecer, al tiempo que mejoramos tiempo y calidad del proyecto
7. Promover las oportunidades de mejoramiento personal para todo el equipo (yo uso mucho el coaching, cursos internos, cursos externos y teambuilding)
8. Evaluar las metas del proyecto y mirar si se cumplirán o no, incluso identificando los posibles riesgos y cómo estar preparados para solventarlos, trasladarlos o ignorarlo
9. Siempre siempre siempre realizar pruebas antes de su lanzamiento a productivo
10. Reportar avances y/o incidencias a sus superiores, incluyendo al PM y en todo caso al Director de Desarrollo y/o de Ingeniería

Finalmente, algo importante a desatacar (y que en particular me ha servido mucho) es que el líder de proyecto e incluso un PM debe de conocer y promover, al menos a nivel general, las mejores prácticas para la administración de proyectos, dentro de las mas importantes puedo mencionar:

• PMBOK (42 procesos y 9 áreas de conocimiento)
• Norma ISO 27000
• Norma CMMI
• Metodología 5s
• Metodología LEGO Serious Play
• Metodología SCRUM Master

Nota: Cabe señalar, que para la mayoría de los líderes de proyecto y muchos PM justifican su falta de conocimiento, incompetencia o ignorancia porque NO SE ENCUENTRAN CERTIFICADOS en x ó y metodología o herramienta... ésto no es un pretexto, ya que actualmente contamos con infinidad de libros y vínculos que pueden ayudarnos a conocer el tema en gran medida.