1.
NASA, caso de éxito en Gestión de Proyectos PMI
La NASA (National Space Agency) es un referente mundial de ingeniería, pero también en
Dirección y Gestión de Proyectos como uno de los más destacados casos de éxito de la comunidad
PMI (Project Management Professional), a la cual lleva aportando conocimientos, experiencias y
herramientas desde hace más de 30 años.
El Dr. Edward Hoffman, director fundador de la NASA’s Academy of Program/Project &
Engineering Leadership (APPEL) señala que “la NASA vive en un mundo de proyectos, con una
bolsa de recursos económicos de 18,000 millones de dólares, y cada centavo que se gasta debe
optimizarse en cada programa y Proyecto”.
La NASA es un claro ejemplo de cómo la formación en Gestión de Proyectos es esencial para el
éxito, sobre todo comparando los resultados de hoy, con los que se obtenían antes de que en
1988 la NASA estableciera el Programa de Gestión de Proyectos del PMI como respuesta para
abordar los déficit culturales y de formación identificados tras el fatídico desastre del
transbordador espacial Challenger.
El desastre del Challenger, a la era de la excelencia NASA – PMI.
Tras la explosión en misión del Challenger, la NASA tomó la firme decisión de cambiar la
organización hacia la excelencia en la gestión de proyectos con el objetivo formando a su personal,
fomentando el aprendizaje de la experiencia de sus ingenieros y profesionales de mayor éxito,
buscando nuevos conocimientos y sinergias con el exterior – la comunidad internacional – y
adoptando las mejores prácticas, camino en el que encontró al Project Management Institute
(PMI).
Con el pasar de los años hasta nuestros días, la gestión de proyectos basada en las prácticas
recopiladas por el PMI en el PMBOK Guide se ha convertido en una de las herramientas más
importantes en toda la organización de la NASA, ya que le ha ayudado enormemente a aprender
de sus proyectos, planificar mejor, optimizar los recursos, y responder al exigente escenario de los
últimos años en el que ha habido que trabajar más rápido, mejor, más barato, y todo ello
experimentando reducciones sustanciales de personal y presupuestos.
Hoy en día la gran mayoría del personal de la NASA está implicada en los cursos de gestión de
proyectos, eventos, publicaciones y actividades de investigación, lo cual también comparten con
profesionales de otras organizaciones como proveedores, socios, colaboradores, etc.,
convirtiéndose así la NASA no solo en un referente de la gestión de proyectos en el ámbito
internacional, sino en un verdadero caso de éxito, y una gran fuente de casos de buenas prácticas
para el PMI.
“Vemos en el PMI y en la Guía del PMBOK el mapa del “planeta gestión de proyectos” declara el
Dr. Hoffman. “Se adapta a nuestras necesidades generales, pero también a las específicas de áreas
como ingeniería, seguridad de materiales, etc.
2. La figura del Director de Proyecto-PMP y el Astronauta
“Ser director de proyectos es el segundo puesto más valorado después del de astronauta en la
NASA” señala el Dr. Hoffman. “Ayudamos a todo nuestro personal a obtener y mantener las
certificaciones profesionales del PMI mediante el programa de formación continua. Muchos
profesionales quieren convertirse en jefes y gestores de proyectos, y la certificación les da la
posibilidad demostrar su conocimiento y capacidad para llegar a directores de proyecto”.
Siendo una de las organizaciones con mayor porcentaje de CAPM’s (Certified Asociatte in Project
Management), PMP’s (Project Management Professional) y PgMP (Program Management
Professional), del mundo, la NASA ha encontrado
en la pertenencia de su personal a la comunidad PMI, una gran fuente de información, formación,
networking, y colaboración. La certificación y pertenencia al PMI permite mantener viva la
formación y capacitación continua de sus profesionales en el campo de la gestión de proyectos,
aprovechando buenas prácticas de muchas empresas: grandes, pequeñas, microempresas, que
incluso en sectores tan diferentes al de la NASA como la metalmecánica, la agricultura o los
medios de comunicación, también son trasladables para mejorar a la NASA.
“Vemos que la gestión de proyectos es una una competencia básica . La NASA cree que los grandes
retos que la sociedad está afrontando tienen forma de proyectos y programas; Y cuanto mayor es
el reto, más útil resulta tener una visión clara y común de su gestión. Responder a los retos con
una gestión eficaz y eficiente nos conducirá a éxitos mayores”.
3. Lecciones aprendidas
Las lecciones aprendidas de la NASA inspiran a los mejores directores de proyecto, ésos que
pueden poner una idea en órbita y consiguen ir y volver a la Luna como quien entra en Facebook.
Sus enseñanzas, las que quieren transmitir a futuras generaciones de responsables de proyecto se
recogen en un compendio que, como el propio Jerry Madden afirma, proviene de todas partes y
no es original siquiera en un 1%. En cualquier caso, resulta enriquecedor y hay que valorar la
iniciativa compiladora que puede iluminar más de una sombra en la dura tarea de la gestión.
Está claro que la NASA es un buen ejemplo de saber lo que está haciendo, algo que, no sólo se
aplica a los cohetes y naves espaciales, sino también al hardware y, por supuesto, al rendimiento.
Teniendo esto en cuenta, cuando la NASA da a consejos sobre cómo gestionar un proyecto, todo el
mundo debería escuchar. Una máxima que perfectamente podría aplicarse a la observancia de
"Las lecciones aprendidas de un director de proyecto".
Pero ¿qué son estas reglas exactamente?
Se trata de 128 normas.
Fueron resumidas en el año 1995.
El encargado de elaborar este compendio fue Jerry Madden, entonces Director Asociado de Vuelo
en la Dirección de Proyectos del Centro Goddard de Vuelos Espaciales de la NASA.
Muchos de los preceptos recogidos en esta lista, y cuya procedencia sigue siendo desconocida,
resultan de extraordinario valor para las personas encargadas de la gestión de un proyecto, y muy
especialmente para los directores de proyectos de software.
Entre las 128 enseñanzas de distintos directores de proyecto que se recogen en esta selección,
cuyo original puede consultarse en la propia web de la NASA, destacan las siguientes:
Regla nº 90: las semillas de los problemas se vislumbran desde el principio y por eso la
planificación inicial es la parte más crítica de un proyecto.
Regla nº 54: todos los problemas pueden solucionarse con el tiempo, así que merece la pena
asegurarse de tener la suficiente disponibilidad horaria para conseguirlo porque, si no, el próximo
jefe de proyecto que tome su posición lo hará.
Regla nº 33: la experiencia puede ser buena, pero la prueba es mucho mejor. Saber que algo
funcionará nunca puede sustituir al valor de la prueba que demuestra que así es. ∙
Regla 6: hay que prestar atención a los adictos al trabajo porque si avanzan en la dirección
equivocada, pueden hacer mucho daño en poco tiempo.
Regla nº 100: el exceso de ingeniería es común. Es sabido que a los ingenieros les encantan los
rompecabezas y los puzles, por eso hay que tratar de obligarles a mantener sus diseños simples.
Regla nº 68: los primeros indicios de que se avecinan dificultades en un proyecto provienen de la
planificación o de la curva de costos. Los ingenieros son los últimos en saber que están en
problemas, lo que demuestra que son naturalmente optimistas.
LECTURA:
sabía que solamente el 2% de los proyectos de software son
exitosos porque fracasan los proyectos de software todo esto y mucho
más en esta edición contento de tenerte de nuevo en otra edición de
hobby con la tecnología hoy quiero compartir contigo algunos
puntos claves de por qué los proyectos de software no son exitosos
entre eso quiero mencionar lo siguiente requerimientos incompletos
cuando se va a desarrollar un software siempre se debe tener un listado
de todos los requerimientos que se deben cubrir en este proyecto para
que el sistema verdaderamente funcione adecuado ahora bien cuando
decimos requerimientos incompletos suele suceder que cuando
se convierta cuando se comienza un proyecto de desarrollo de software
y se comienza a trabajar se consiguen que algunos de los
requerimientos no están claros o no están y resulta que entonces te
hace desarrollar o te hace trabajar mucho más de lo que se estimó
porque simplemente no se detuvieron a identificar bien
los requerimientos otro punto importante es que el cliente final se
involucra muy poco en tu proyecto suele suceder que el proyecto owner
o el dueño la solución no tiene tiempo no se involucra no quiere
participar en las reuniones sino que él simplemente lo que quiere ver es
el software pero no tiene tiempo para detenerse a evaluar un diagrama
o para poder evaluar los requerimientos cuáles son las fases del sistema
qué resultados quiero obtener con la solución no entonces como no
se involucra es muy probable que tu proyecto fracase porque cuando
ese dueño del proyecto o tu cliente venga a ver la solución ya la
avanzada en su desarrollo por supuesto que se van a conseguir cosas
que se pueden prevenir en el en el principio porque se está la
persona doliente o la que tiene vamos a decir las bases de las reglas de
negocio claras para que el desarrollo sea verdaderamente oportuno falta
de planificación y estrategia esto suele pasar mucho si no se define
una planificación y hasta una metodología adecuada puede fracasar tu
proyecto porque si no tienes claro tiempos de entrega o lo que llaman
dent line que tu proyecto lleve un flujo verdaderamente adecuado
también a los requisitos de la empresa o de quien solicita el software si
no hay planificación y estrategia un proyecto puede fracasar otro punto
importante es falta de soporte desde la gerencia muy parecido al
anterior este donde no se involucra el dueño si la gerencia que requiere
o solicita la solución no se involucra constantemente va a
haber problemas no y eso es importante también cuando hablamos del
tema de soporte porque el soporte viene dado a qué cosas normalmente
identificamos que puedan fallar o que nuestra experiencia nos dicen que
van a fallar y como yo tengo preparado un escenario para poderlo cubrir
otro punto importante requerimientos y especificaciones en continuo
cambio suele suceder que dependiendo la metodología que tú utilices en
un desarrollo de software constantemente tengas
nuevos requerimientos y nuevos cambios con los que estás presentando
y fui en que esto suele suceder por no en los requerimientos iniciales
entonces están saliendo nuevas historias de usuario a medida que
vamos desarrollando que es normal pero si no se planifica bien y no se
ejecutan estratégicamente vas a tener una solución que nunca va
a terminar porque siempre empiezan a salir nuevos requerimientos por
eso que es importante definir un producto mínimo viable porque de
pronto hay nuevos requerimientos que no son mínimos y no son
necesarios para la primera versión de tu sistema otro punto importante
es que los recursos del proyecto sean muy cortos o insuficientes que
puede suceder que un proyecto requiere una inversión interesante
económica y también de tiempo y de trabajo de un equipo y si no están
bien esos recursos un proyecto puede fracasar porque pueden
comenzar muy bien con muy buenos recursos pero si los van
disminuyendo se van saliendo algunos stakeholders o se van
saliendo algunos especialistas del proyecto y el acabado no va a ser lo
mismo y el resultado no es lo mismo entonces cuando no se tiene
suficientemente ingresos o presupuestos para un proyecto puede hacer
que esté otro punto importante es que el proyecto a medio desarrollo
deja de ser necesario se pronto se tardó mucho en la planificación en la
estrategia o en el desarrollo y nos damos cuenta en un equis tiempo que
ya la solución no funciona o hay otro requerimiento adicional o
simplemente lo que estamos haciendo no va a solucionar el
problema que se requiere o se soluciona de otra forma otro punto
importante de dejar el proyecto en manos de solo programadores y
fíjense esto que quiero hacerlo muy respetuosamente y con todo el
respeto bueno que se merecen los programadores porque también en
algún momento fue programador pero un programador viene a viene a
ser no necesariamente el gerente de software el debe a el diseñador el
en marquette a dorel va que en el front end hay muchos stakeholders en
un proyecto de desarrollo y no puede dejar todo en manos de un
programador es como si tú fueras a construir una casa o una vivienda y
todos los dejen en manos de un obrero qué pasa con el arquitecto con el
ingeniero de obras el electricista con el ingeniero civil con el decorador
con el electricista son muchas cosas entonces no puede dejar
un proyecto solamente en manos de un programador y ya por último y
para terminar estas estos puntos que pueden hacer que tu proyecto de
desarrollo fracase es que esté en el proyecto involucrados terceros que
no tengan nada que ver primero con el área de experticia o que tengan
conocimientos de lo que vamos a hacer suele suceder que hay
consultores de consultores o asesores de asesores que
están involucradas e involucrado en un proyecto y no aportan valor sino
que simplemente van basado en un criterio x lo que pueden es
entorpecer el proceso y hacer que éste mismo fracase
entonces importante cuando vaya a desarrollar un proyecto de software
toma en cuenta todos estos puntos para que verdaderamente sea
exitoso y que desde y que de una vez por todas con una
buena planificación y estructura puedes hacer que un proyecto sea
verdaderamente explosivo que llegue a lo que tú estás buscando y para
todo eso puedes contar con la asesoría y el apoyo de su leaf tech y si es
modeler que somos especialistas en el desarrollo del software no vemos
en otra edición esto es poco con la tecnología