3 TENDENCIAS EN LA GERENCIA DE PROYECTOS PARA 2017

by  Harvy Cruz Girón - Máster Project Manager / Máster Information Systems Security



Cada comienzo de año, tanto nuestros clientes como nuestro equipo se preguntan: cuáles serán los cambios que observaremos este año en nuestro negocio? Cuáles serán las tendencias que nos obligarán a efectuar cambios en nuestro negocio a fin de adaptarnos a esta economía de trabajo global?


Bueno, realmente nadie tiene una bola de cristal para prever lo que exactamente sucederá, sin embargo es un ejercicio válido el reflexionar sobre lo que ha sucedido en el último año, y a partir de allí empezar a figurarse las predicciones para este nuevo año que apenas comienza.


En el año 2016 dentro del ámbito de la gerencia de proyectos observamos tendencias como la nuevas implicaciones de los cambios en la fuerza de trabajo a nivel local y global, el aumento y la continua divulgación de los éxitos y retos de las metodologías ágiles más allá del desarrollo del software, y el incremento, y constante re-diseño de los roles de los Gerentes de Proyectos (PM) y de los Analistas de Negocios (BA).


El sentido común, la experiencia y las innumerables conversaciones con colegas y CEOS nos acercan a considerar algunas de las tendencias que observaremos en el 2017. Yo ofrecería los siguientes tres aspectos como las tendencias más relevantes dentro del marco de la gerencia de proyectos: El nuevo rol de los Analistas, el cambio a una Gerencia de Proyectos adaptable y el ingreso de los Generalistas.


1- El nuevo rol de los Analistas.

Re-evaluando a Los Analistas (BA) de Negocios

Definitivamente el gran éxito que ha tenido Agile (Scrum, Scaled Agile, y Nexus) en la gerencia de proyectos de desarrollo de software, también nos ha mostrado abiertamente las limitaciones del modelo Agile en el manejo de proyectos complejos y de grupos multidisciplinarios grandes, lo cual nos lleva a re-evaluar nuestra posición inicial frente al rol del Analista.


Dentro de los proyectos que podemos denominar como grandes, no es un secreto que todos quienes participamos dentro de un modelo Agile reconocemos que existe una necesidad y un mayor esfuerzo en la coordinación, integración y comunicación entre los equipos Agiles que tratan de desarrollar las diferentes soluciones del proyecto… Y que no importa el título que queramos darle, las personas encargadas de estas responsabilidades estarán siempre incluidas en áreas relacionadas con el Análisis. Los Analistas, quienes siempre han sido necesarios en proyectos de gran escala, nos mantienen integrados para el logro de objetivos comunes ( la coordinación de las dependencias, la seguridad, los impactos organizacionales y técnicos, y el control de versiones).


Sin embargo hemos observado cómo algunas organizaciones que ya han adoptado Agile como panacea y posible solución a sus dolores de cabeza, lo han hecho “a su manera”, sin percatarse que la adopción de Agile a nivel organizacional, como marco de referencia, requiere no sólo de personal familiar con Agile, sino que exige el entendimiento y manejo por parte de todos los participantes, de esta nueva forma de interactuar con otras organizaciones, los stakeholders y los project owners, de manera de poder garantizar consenso, es decir, el manejo efectivo de la resolución de conflictos, la capacidad de influenciar, y pensar tanto de manera crítica,como imparcial y creativa dentro de la organización. Normalmente estos atributos mencionados están incluidos en los roles del Analista, y actualmente no se encuentran integrados en el esquema de trabajo Agile, donde se supone de manera a veces preocupante, que un desarrollador puede al mismo tiempo formular los requerimientos del cliente, establecer los alcances del proyecto, controlar versiones y manejar problemas con el cliente, mientras soluciona sus problemas técnicos.

Estaremos presenciando el nacimiento del Analista Agile?



2- El cambio a una Gerencia de Proyectos adaptable:

La transformación de los roles del Gerente de Proyectos (PM) a los mil tonos de gris, entre el Blaco y el Negro.

Para todos quienes nos ganamos la vida en este negocio, hemos vivido y visto como nuestros roles cambian tan rápidamente que a veces parece una locura el poder  adaptarse. En muchos casos nuestros roles se han visto combinados (Analista-Gerente de Proyectos ó Analista-Control de Calidad-Gerente de Proyectos, Gerente de Proyectos-Scrum Master, etc.), en otros casos hemos experimentado separación, es decir, el híbrido Gerente de Proyecto & Analista, ó PM-Scrum Master, se convierten en dos trabajos a tiempo completo, con dos personas completamente independientes.


Es así como en algunas organizaciones hemos tenido la oportunidad de ver QA leads dirigiendo proyectos de desarrollo, y manejando expectativas de product owners (PO, Clientes); en otras hemos observado como equipos de desarrollo están a cargo del testing (QA), mientras que algunas organizaciones literalmente obligan a Gerentes de Proyectos y Analistas a asumir roles de Scrum Masters… o lo que es más interesante: Gerentes de Proyectos son convertidos en Product Owners sin autoridad de tomar decisiones. Sin embargo lo interesante a mi modo de ver, es que a pesar de todo esto, los PM continúan trabajando desde el área estratégica, es decir, construyendo posibles escenarios y soluciones + casos de negocio, y recomendando soluciones a problemas organizacionales propios o del cliente.


A este punto, estoy seguro que se estará preguntando: … y entonces cual es la tendencia? Bueno, en lo inmediato como vimos, los roles y títulos variarán de una organización a otra… y cómo también observamos, el Gerente de Proyectos trabajará de las dos maneras: Táctica y Estratégicamente, como siempre ha sido requerido y como siempre ha sido necesario, sin importar la descripción formal del empleo o el título del cargo (rol). En sus funciones tácticas y estratégicas, aportará un valor agregado efectivo para la organización, donde no sólo colaborará como interface con los clientes y el grupo de desarrollo, sino con áreas como operaciones, seguridad, integración, infraestructura, soporte y ventas, mejorando la comunicación y la cohesión del equipo.

Project Manager + Scrum Master? Si... así es. En la vida real existen!



3- El ingreso de los generalistas:

La descripción de los puesto de trabajo son una clara indicación de cuan especializado puede llegar a ser nuestro mercado de trabajo. Sin embargo hemos notado, como la experiencia dentro de una organización trae consigo un nuevo y anónimo rol, más flexible, y adaptable a las necesidades inmediatas y siempre variables de la empresa: El Generalista.



Es así como veremos Analistas que programan, Ingenieros que son Gerentes de Proyectos, y Gerente de Proyectos que soportan áreas de ventas, por ejemplo. En este caso, las organizaciones se adaptan rápidamente a cualquier requerimiento externo, y cada miembro del equipo participa activamente en ese auto-re-ordenamiento que hará más competitiva a la organización. Aquí, no sólo la organización es capaz de reorganizar su equipo, sino que el equipo es también capaz de adaptarse rápida y flexiblemente en la ejecución de las tareas de deben realizarse pronto, por lo cual entre más diversas sean las habilidades de sus miembros, más rápidamente podrán efectuarse las tareas del equipo. Estos equipos auto ajustables permiten a sus miembros trabajar en diferentes roles, y hacer que las cosas sucedan según sea necesario como una respuesta inmediata a una influencia externa. Por supuesto esto no es nuevo, sin embargo ahora empieza a observarse como algo ya normal y común.

Con optimismo espero que esta información nos ayude a mantener nuestras expectativas abiertas durante este año 2017.  

ALTRUISMO AGILE, UNA FALLA DEL EQUIPO...

by  Harvy Cruz Girón - Máster Project Manager / Máster Information Systems Security

Es su empresa una organización liderada por un estilo Agile donde el logro de los objetivos depende del altruismo y la “buena fé” de su equipo? En conversaciones con varios gerentes de proyectos de diversas compañías consultoras y de outsourcing ese pareciera ser el caso, y ellos se muestran orgullosos de que así sea.

Por favor no lo tomen a mal. No hay nada malo con el altruismo y la buena fé. Todos sabemos que grandes obras de caridad dependen para su éxito de la generosidad, y la buena fé de los seres humanos. Sin embargo, en un proyecto el proceso en el cual un individuo se convierte en un empleado está muy lejos de ser un contexto basado en la caridad o la buena fé.

Por experiencia, todos los gerentes de proyectos sabemos que la formación de cualquier equipo va generalmente acompañada, entre otras, de limitaciones presupuestarias y dificultades con los costos de contratación. El costo de la formación de un equipo para un proyecto es siempre un problema y créanme NO es una excepción. Sólo recordemos que el costo de cada miembro de un equipo va soportado por los niveles de producción que justifiquen los beneficios que obtendrá la organización -quien paga, a cambio del trabajo del equipo.

Cuando creamos un equipo siempre nos basamos en los requerimientos del cliente, y el ensamblaje de ese equipo inequívocamente reflejará las limitaciones de costos (que ya vienen incluidas dentro de los requerimientos). Por ejemplo, debido al factor costo veremos que algunos miembros tendrán más experiencia que otros, diferentes niveles de educación, mayor o menor conocimiento de estándares y herramientas, incluso algunas veces para cumplir con las exigencias del presupuesto hasta tendremos que contratar personal sin experiencia. Cuando agregamos a esto la presión por lograr una curva de aprendizaje uniforme para todo el equipo, de manera que se puedan alcanzar los objetivos del proyecto a tiempo, veremos cómo el comportamiento, basado en las diferentes expectativas de cada miembro del equipo, saldrá a flote, ocasionando las primeras dificultades en la ejecución del proyecto.

Una ejecución liderada por altruismo puede conllevar a una falla del equipo y por ende al fracaso del proyecto.

HE AQUÍ ALGUNAS FALSAS CREENCIAS A ESTE RESPECTO:


1- Falso - Los objetivos del equipo se sobre pondrán a los intereses personales. Es como decir que nadie dirá YO durante una conversación del equipo. Alguien tiene que ser responsable… y ese alguién ejercerá toda la presión para que las cosas se den como está estipulado, con la ayuda del grupo o sin su ayuda. Esto es fácil de observar cuando se intenta recuperar un proyecto.

2- Falso- La cooperación dentro del equipo automáticamente creará una relación de trabajo altruista donde todos los miembros del equipo son igualmente responsables. Así como el día sigue a la noche.

3- Falso - La competencia sana e igualitaria -y la cooperación- entre los miembros del equipo creará un mejor y más estable (permanente) empleado. De nuevo, quienes compiten: Senior contra novicios?, profesionales altamente calificados y experimentados contra novatos?

En realidad todos sabemos que de la competencia (en general) y la cooperación (en particular), siempre emergerá un equipo de trabajo más efectivo y superior. Al iniciarse un proyecto veremos como un programador senior y experimentado siempre tomará la delantera con respecto a otros miembros del equipo. Pero quiénes se quedan rezagados generalmente tienden a profundizar en los más minimos detalles de las especificaciones y sólo el “bautismo con fuego” hará sobrevivir a unos y hundirse a otros. Quiénes lo sobrevivan obtendrán el beneficio de la experiencia, pero cabe preguntarnos: Hará esta situación mejores, más leales y estables empleados? Ayudará esto a convencer a todos los miembros del equipo que es mejor una actitud altruista? Hará esta situación que ellos evolucionen -como la noche sigue al día- hacia un liderazgo Agile y altruista? Realmente lo dudo.

Es mi experiencia -Agile o no Agile- que los equipos de trabajo sólo son exitosos debido a las siguientes razones:

1- Los niveles de experiencia deben ser similares. Al no existir disparidad en la experiencia habrá un nivel de cooperación intrínseco enfocado en el entendimiento del problema y su contexto, lo cual se convierte en un objetivo común que todos los miembros del equipo compartirán.

2- La competitividad dentro del equipo debe ser vista como un juego cooperativo donde todos ayudamos a comprender rápidamente la naturaleza del problema y sus contextos. Cada quien probablemente a diferentes velocidades, pero todos cooperativamente nos pondremos al día. No es esto realmente altruista?

3- El equipo durante la travesía del proyecto será cada vez mejor y mejor como equipo. Esto conlleva a tener mejores y más leales empleados.

4- Un objetivo es más que la generación rápida de una versión de algo… y un equipo efectivo es la relación armónica entre personas con gustos y aptitudes disímiles.

5- En el ejército el instinto personal -el YO- de los soldados es sobrevivir a la misión… y el soldado comparte este mismo objetivo con todos los involucrados en la misión, aún cuando su foco es ser exitoso en sobrevivir él por su cuenta la misión. Tomemos por ejemplo un proyecto de desarrollo de software. Allí nada es de vida o muerte, por lo menos no para los desarrolladores, puede ser que para el cliente! El punto es, que no hay un objetivo personal y a la vez común a la hora de desarrollar el producto, y sea este un equipo Agile o no, el objetivo del proyecto escapa del equipo y ese compromiso debe ser internalizado a nivel personal… esto es parte importante, y es una de las muchas cosas que convierte a individuos disímiles en un equipo.

Agile-Scrum está fundado en la teoría empírica del control de los procesos, o empirismo; Y el empirismo declara sin lugar a dudas que el conocimiento sólo viene de la experiencia, y que toda decisión debe hacerse en base a lo que es conocido. Por lo tanto la experiencia dicta que es importante tener presentes las diferencias sociales, educativas, geográficas, étnicas y culturales al momento de ensamblar un equipo exitoso.

Últimamente se nos repite hasta la saciedad, que la tecnología y el Internet nos ha convertido en un mundo igualitario y plano, pero para bien o para mal, la naturaleza humana está muy lejos de ser plana o igualitaria, cada quien es cada cual, y baja la escalera como puede. Este es nuestro instinto personal, y es nuestra labor como gerentes recordarlo con prudencia y responsabilidad.

LA INDEPENDENCIA DEL SOFTWARE

by Harvy Cruz Girón - Master Project Manager / Master Information Systems Security


En febrero de 2003 Marc Benioff, un desconocido practicante del budismo y director de una también entonces desconocida firma llamada Salesforce.com, anunció en un concierto benéfico, en el que participaba el definitivamente conocido David Bowie, su entonces novedosa visión sobre "La Independencia del Software".


Religión, música, tecnología, y dinero fueron una combinación inusual para un mensaje donde la tecnología que presentaba Benioff realmente prescindía en sí del software. Los clientes podrían acceder a los servicios de Salesforce.com utilizando sólo un navegador web, lo cual les ahorraría miles de dólares y la incomodidad de administrar y mantener costosos servidores y complicadas redes de computadores personales, a fin de utilizar un sofisticado programa multiusuario de gestión de relaciones con el cliente, comúnmente conocido como CRM (Customer Relationship Management). Para finales de ese mismo año 2003, más de 6300 clientes en 110 países ya estaban utilizando el nuevo producto, lo cual generó alrededor de 52 millones de dólares para la empresa de Benioff.


La independencia del software y su nuevo concepto, The Cloud -La Nube, hacían su formal debut en este evento cultural de Nueva York, y Benioff predecía que "El internet marcaría la muerte del modelo industrial de software tradicional"


Si usted es un escéptico como yo, seguramente argumentaría que Benioff no es un líder en innovación sino un sobreviviente casi solitario, de la crisis de las puntocom (1997-2001). Fué durante este boom que miles de empresas lanzaron servicios de aplicación en línea (ASP) pero finalmente muy pocas tuvieron éxito. La razón: La tecnología disponible en aquel entonces hacía extremadamente difícil asegurar un servicio de software resiliente y con calidad. Pero como ya sabemos, esto no sería por mucho tiempo.


Debemos dar mérito de que la idea propuesta por Benioff y otros no era tan descabellada como sonaba. La historia nos demuestra que toda tecnología tiene un proceso de maduración, y es durante ese proceso que comienzan a desarrollarse diversas opciones para ofrecer a los clientes alternativas de cómo obtener dicha tecnología. Recordemos como en los primeros tiempos de la electricidad JP Morgan contrata a Edison para construir sus propios generadores. Por contraste, hoy día cualquiera puede obtener su energía de la red pública.


Una mejor manera o el fin de un círculo perverso

Después de muchos años trabajando como consultor en tecnología y como ejecutivo para empresas grandes, medianas y pequeñas, pertenecientes al Fortune 500 o no, local y globalmente, honestamente reconozco que cuando se trata de software empresarial, existe un modelo  de mercadeo -un circulo económico, casi perverso. El software que es en su esencia un servicio digital, es vendido como un bien de producción. Es decir, los clientes tienen que pagar enormes sumas de dinero por adelantado, soportar casi todo el riesgo de que la aplicación no funcione como fue prometido, quedando atrapados en sofisticados contratos de soporte/mantenimiento, y con generalmente muy pocas posibilidades de cambiar de proveedor.
  
Mientras, las compañías desarrolladoras de software gastan a manos llenas en complejos sistemas de mercadeo y distribución, en lugar de enfocarse en desarrollar mejor software, de mejor calidad y que funcione, y que sea fácil de mantener y usar. La situación no se ve mejorar cuando observamos el desenvolvimiento de estas corporaciones en la bolsa de valores.

En el mercado de la tecnología muchas veces ser el primero es una gran ventaja, puesto que altera las expectativas de los especuladores bursátiles quiénes invierten grandes sumas en rubros tecnológicos… esto permite que los vendedores de software se vean tentados en poner en circulación programas aún en estado de prueba, releases one - versiones 1 plagadas de errores y fallas (recordemos a Oracle y Microsoft con sus lanzamientos prematuros).

Debido a esto no es especulación decir que toda empresa de software es una inversión riesgosa, ya que estas empresas a efecto de causar impacto en el mercado deben crecer más rápidamente que el promedio (ejemplo apple) a fin de justificar sus relativamente altas cotizaciones en la bolsa, aún cuando esto signifique vender más licencias de programas de los que sus clientes necesitan, o productos que están en fases beta avanzada.

Aquí es cuando encontramos una de las peculiaridades insanas de la industria del software: “El Software de estantería”; Un término se aplica a todas aquellas licencias que son distribuidas o “vendidas” pero que nunca serán utilizadas. Este fenómeno causa el crecimiento acelerado de las empresas tecnológicas, a costa de una “hipoteca a futuro” que se desploma cuando al final del ejercicio fiscal, dichas “ventas” son difíciles de justificar y la organización entra en una proceso de negociaciones imprudentes que generan crisis de las cuales casi nunca logran recuperarse. Recordemos Oracle en 1991, cuando el gigante de las bases de datos casi se desploma al no cubrir las expectativas de los analistas de wall street.

El mundo de la tecnología ha madurado muchísimo en la última década. Tecnologías emergentes como la nube, la movilidad y las redes sociales, todas relativamente nuevas, han conducido a un mejor equilibrio en el sector informático y de las telecomunicaciones. El internet es ahora un producto estable y de calidad, que ha hecho posible las direcciones de ASP, como Salesforce.com, pero también ha permitido a los fabricantes de hardware monitorear sus servidores y desarrollar nuevos modelos de negocios donde cobran a sus clientes sobre una base aproximada del promedio del uso de recursos informáticos por mes.

Con el amplio despliegue y la masificación de los servicios web, y en la medida que los centros de datos se automaticen y sean accesibles a través de la nube,  la informática tal y como la conocemos se convertirá en un servicio público. La nube que ahora hace accesible y permite compartir recursos informáticos a cualquier nivel dentro de las organizaciones, también permitirá la utilización de recursos bajo un modelo de demanda, esto es decir, pagar por lo que realmente se necesite o utilice. Ya no será necesario operar nuestros propios servidores especializados, ni construir nuestras “propias plantas eléctricas”. Probablemente todo el software que necesitemos estará contenido en una suerte de API accesible ON DEMAND.

EL FUTURO DE LA GERENCIA DE PROYECTOS

by Harvy Cruz Girón - Master Project Manager / Master Information System Security

Según el Standish Group en su reporte CHAOS del 2013, sólo 39% de los proyectos son entregados a tiempo, bajo lo presupuestado y con las funcionalidades que han sido requeridas. Roger Sessions en su libro The IT Complexity Crisis va más lejos y cuantifica que resolver este sólo problema en la falla de la entrega de proyectos, incrementaría automáticamente el GDP de los Estados Unidos en un trillón de dólares al año y ahorraría 500 billones de dólares al mes a nivel de la economía global.


La Gerencia de Proyectos no es una profesión nueva. Para algunos ni siquiera es una profesión, sino un trabajo donde alguien maneja colecciones de actividades a fin de alcanzar ciertos propósitos. Para otros, es una disciplina, una profesión especializada y relacionada con áreas de negocios constantemente en cambio y llena de retos al momento de emprender nuevas iniciativas debido a las complejidades implícitas de un mundo de los negocios globalizado.


Gerencia de Proyectos: Las medidas del éxito

En términos generales en el siglo XX ( y aún en nuestros días ) muchos medían el éxito de un proyecto con métricas tales como la entrega a tiempo, bajo lo presupuestado y dentro del alcance acordado (scope). Como consecuencia de esto, y con el pasar de las décadas, se perdió el enfoque original y la razón inicial de cualquier proyecto en términos del agregar valor para el cliente, y generar bienestar o riqueza que se revierta sobre los involucrados y dueños de dicho proyecto.


De nuevo, si utilizaramos las métricas antes mencionadas observaríamos que a comienzos de los años noventa sólo 15% de los proyectos alcanzarían el éxito. Pero también notaríamos que a finales del siglo XX si bien hemos mejorado enormemente, sólo alcanzamos en el mejor de los casos un 39% promedio de éxito en la entrega.

Decididamente estos números sólo nos demuestran la necesidad de transformar de manera inmediata nuestra práctica de la gerencia de proyectos, a efecto de enfrentar adecuadamente los retos del siglo XXI. Si bien es verdad que algunos gerentes de proyectos ya trabajan a niveles altamente estratégicos, no podemos negar la cruda realidad de que la vasta mayoría de nuestros gerentes todavía siguen atrapados en las viejas dicotomías:
  • Admininistar vs Hacer
  • Gerenciar vs Liderar
  • Orientación táctica vs “El cómo deberían operar los sistemas”
  • Gerencia de los requerimientos del proyecto vs Administración de complejidades
  • Hacerlo como siempre vs Innovar
  • Logro de milestones vs valor para el cliente

El siglo XXI  supone nuevos retos en la manera como iniciamos y gerenciamos el cambio en nuestras organizaciones -ahora globales, y la gerencia de proyectos, junto con los gerentes de proyectos, nos veremos involucrados directamente al momento de acometer iniciativas donde ya no basta con seguir filosofías, estándares y metodologías para alcanzar metas propuestas. Ahora se trata de agregar verdadero valor a la industria y a los consumidores de nuestros servicios, enfocándonos en soluciones creativas y aprovechando las ventajas competitivas que nos ofrece el uso de nuevas tecnologías convergentes como las redes sociales, la mobilidad y el internet de todo/en todas partes.

Hoy día las organizaciones no encuentran el talento necesario que requieren para negociar diariamente los cambios y/o manejar las incesantes complejidades provocadas por estos. Las organizaciones necesitan de pensadores estratégicos, creativos con la habilidad de adaptar, inventar y re-inventar. Colaborar, crear e innovar entendiendo  y sacando provecho de las complejidades que conlleva un siglo que estará demarcado por una inestabilidad provocada por acelerados cambios tecnológicos y mercados emergentes que exigen enfocarnos ya no en los requerimientos sino en soluciones que generen valor a través de transformación y re-ingeniería.

CIOs de todo el mundo están reconociendo que los Gerentes de Proyectos (PM) son clave para el éxito corporativo.


Pero en este caso no estamos hablando del Gerente de Proyectos que todos conocemos; Estamos hablando de una nueva definición del rol del PM enfocado en soluciones con visión estratégica y no sólo ejecución táctica. Profesionales capaces de avanzar a un nuevo nivel de liderazgo dentro de la estructura organizacional, capaces de gerenciar cambios y generar valores agregados provenientes de dichas transformaciones.

El mensaje es claro: De ahora en adelante el éxito de un proyecto se medirá por el valor agregado que genere para el cliente y en el fondo, sólo por su capacidad de generar riqueza e innovación.