Archivo de la etiqueta: gestión de proyectos

Lo que PMP no te enseña de la gestión de proyectos

Seré sincero: he estado a punto de titular este post “La gestión de proyectos según el Dr. House”, pero resultaría pretencioso. Así que dejémoslo como está; todo lo que escribiré aquí es puro zumo de realidad, tras 14 años de experiencias muy diferentes en el mundo TIC y de haber cometido todos y cada uno de los errores que resumo en este decálogo. Espero que os sirva de algo a los recién certificados, Jefes de Proyecto Junior y demás neófitos en esto del Project Management.

I. Conoce a los verdaderos interesados antes de iniciar el trabajo.

Tomar requisitos no es una tarea rápida ni objetiva. Normalmente, en las sesiones de toma de requisitos hay mucha gente con grandes requisitos de nombre bonitos (escalabilidad, robusto, calidad total, ISO), y que presume de haber leído “El arte de la guerra”. Pero todos se suelen obviar al usuario final del aplicativo o servicio, normalmente un administrador muy abajo en el organigrama corporativo. Lo paradójico es que es esa persona o grupo de usuarios quienes normalmente van a validar gran parte de las funcionalidades. Encuéntralo y no lo sueltes hasta conseguir los requisitos ocultos.

II. Controla los riesgos obvios que siempre se infravaloran.

Si tu chárter no ha sido firmado o nadie ha asumido el rol de sponsor, éste es el primer riesgo a tener en cuenta. Sin sponsor, no hay proyecto ¿Quién va a escucharte cuando levantes la bandera roja? ¿A quién vas a recurrir para cuando tengas problemas con la factura de la Fase N? ¿Cómo vas a discriminar las funcionalidades core de la carta a los RRMM?

El contrato y el Acuerdo de Nivel de Servicio (SLA) son la biblia. Si desconoces alguno de ellos, ese es el segundo riesgo evidente a tener en cuenta.

III. Usa una metodología adecuada para cada proyecto.

No intentes encajar tu proyecto en los marcos de trabajo que conoces, hazlo al revés. PMI no es tu cliente, ITIL no suele ser el marco más representativo de la organización de tu cliente, CobIT está en otro planeta, scrum es considerado en muchas organizaciones “una fricada”. Mantén el orden interno, pero sé práctico. Parafraseando a Bruce Lee: “si pones agua en una tetera, el agua se transforma en la tetera”… Be water, my friend!

IV. Empieza a definir el alcance del proyecto por los informes.

Ahí es donde encontrarás los detalles que definen la capa de acceso a datos, además de gran parte de la propia lógica de negocio. Entiende los informes que necesita el Departamento de Contabilidad y entenderás el negocio mejor que el propio Jefe de Producto.

Es muy común dejar los informes para el final, para la última fase del proyecto, y suele ser ese el momento en que te das cuenta de que alguno o varios de los informes no encajan con tu modelo de datos. Así que, no cierres el alcance del proyecto hasta que consigas que el cliente haya definido los informes de salida y estés seguro de haberlos comprendido completamente.

V. Define el core del proyecto y cíñete al plan.

Es típico en los proyectos TIC que las funcionalidades no estén cerradas incluso tras lanzar el proyecto y que haya que hacer modificaciones al vuelo. Bien, no hay problema, siempre que hayas definido las funcionalidades para alcanzar un mínimo producto viable. Si lo has hecho, pero aún así hay que modificar la funcionalidad del core,que sea solo a la baja ¡Por algo es el core! El resto faséalo y admite modificaciones sólo tras el cierre de la primera entrega o verás como los cambios sobrevenidos hacen tambalearse toda la arquitectura.

VI. Piensa bien qué hitos son fáciles de conseguir y espácialos adecuadamente durante las fases.

Si algo hemos aprendido de toda la literatura sobre gestión del cambio es que una mala gestión de expectativas puede hundirte el proyecto. No hay misterios: la agenda (política) del cliente marcará los entregables, tengas o no algo que entregar, por lo que deberías reservar algunos cartuchos. Y cuando llegue el momento, permite que sea tu cliente quien difunda los éxitos internamente.

VII. Cometerás errores; asúmelos lo antes posible y trata de solucionarlos sin buscar excusas.

Te han contratado para solucionar problemas o al menos mitigarlos, no para crearlos. Una forma muy común de generar problemas es ocultar los errores propios, porque los problemas que no se arreglan inmediatamente tienen muy mal envejecer: siempre, siempre, siempre empeoran.

VIII. Sé duro con tu cliente.

No has venido aquí para hacer amigos. Con suerte, puede ser que lideres un proyecto en una compañía que se esfuerza en ser un “human workplace”, favorece el after-work y trata de ofrecer un ambiente “friendly”… pero eso es para el equipo en casa del cliente, no para tí. En ningún caso te hagas amigo de tu cliente (para eso ya está el Director Comercial) porque llegado el momento de negociar un cambio de alcance o el cierre del proyecto… Bueno ¿Quién no ha salido perdiendo en una negociación con un amigo?

IX. Prepárate para que sean duros contigo.

Es lo mejor que te puede pasar. Si esto último no ocurre desde el principio, ten por seguro que los problemas vendrán al final del proyecto, cuando ya no haya tiempo de reacción.

Como corolario, sólo cuando las cosas pinten realmente mal será cuando aprendas a hacer las cosas bien de una vez.

X. Y aún así… Muchos de tus proyectos fallarán.

Las estadísticas dicen que la mayor parte de los proyectos no llegan a ver la luz porque no cumplen la funcionalidad esperada o porque el usuario no ha asumido el cambio (y vuelta al capítulo 4 de PMBOK, o al primer capítulo de este decálogo).

Esto es lo que ocurre en la vida real: por muy bueno o senior que seas, la mayoría de tus proyectos fallarán: anticípate. ¿Cómo? Valora los riesgos en su medida real, sigue el proceso, comunica retrasos y cambios de la línea base al sponsor y todos los interesados… Pero no te confíes: que el sponsor asuma los riesgos no implica que asuma las consecuencias de su materialización. Si constatas que la probabilidad aumenta pero no ves a nadie preocupado, quizá no sea mala idea ir buscando un nuevo proyecto.

Anexo 1 (por cortesía del Dr House): Recuerda que todos mienten.

Perdonad que al final haya sucumbido al encanto del Dr. House, pero es totalmente cierto. Hay que decir en favor del cliente que la mayor parte de las veces no se da cuenta de que miente. Si recibes una documentación con un wsdl de hace dos años, comprueba por ti mismo que los métodos aún existen ¡Sorpresa, ni siquiera responde! ¿Te ha mentido? No, simplemente “no tiene tiempo de pensar en eso ahora”. Así que no remolonees, piensa por ti mismo y trabaja duro para descubrir la verdad.

Autor: 

https://www.linkedin.com/pulse/20140703220301-22118661-lo-que-pmp-no-te-ense%C3%B1a-de-la-gesti%C3%B3n-de-proyectos

Deja un comentario

Archivado bajo Gerencia de Proyectos