Busca en este sitio:
Twitter
. Soy Novato
. Soy Gerente de Proyectos
. Quiero ganar más
. Quiero mejorar a mi empresa
y sus proyectos
. Tengo experiencia, pero no soy experto
. Soy experto (o eso creo)
.
Contáctanos
Escríbenos a:
contacto@liderdeproyecto.com
Para información de cursos:
cursos@liderdeproyecto.com

Teléfono en México D.F:
+52 (55) 2652 4590


Aviso de privacidad
+
.
Aliados del PMI® México

LiderDeProyecto.com es aliado estratégico del PMI® Capítulo México.
+
.
Humor del Líder

Método para contratar personal.
+
.
Glosario
Ven a conocer el glosario de administración de proyectos. Nuevas definiciones: Condiciones, Diagrama de flujo, Proceso de negocio, Producción, Secuencia.
+
.
Colaboradores

Conoce a los colaboradores de LiderDeProyecto.com. Tu puedes ser uno de ellos.
+
.
 
Artículos
 
Características del Gerente de Proyecto de IT

Por Norberto Figuerola (PMP) [ acerca del autor ]

Los CIO’s de empresas tecnológicas han manifestado que desean ver las características y skills de un PM entre sus empleados. Basándonos en un estudio de Computer Economics, el deseo por obtener Project Managers se mantiene constante o en aumento, del mismo modo es manifiesta la eficiencia que adquieren las empresas con oficinas de proyecto formales (PMO’s) y que tienen institucionalizado una buena estructura de gestión de proyectos.

Ahora bien, ¿las características generales de un gerente de proyecto de IT son diferentes a las de otro colega que trabaja en otra industria?. En principio la respuesta es NO, las competencias de un PM de IT tienen como base las mismas particularidades que son necesarias para dicho puesto en cualquier otra industria, aunque de todos modos deberíamos destacar algunas diferencias.

En primer lugar cuando hablamos de IT ¿a qué hacemos referencia? Indudablemente a la gestión de proyectos desarrollados en la industria informática. Pero la industria de IT ha evolucionado tanto en los últimos tiempos, que esas simples letras “Information Technology” engloban perfectamente a proyectos tan diferentes y complejos como el desarrollo de software, la implementación de un ERP o enlatado, la instalación de una infraestructura de networking, el desarrollo de un Data Warehouse, cualquier desarrollo basado en Web, el mantenimiento de un legacy software, un proyecto de reingeniería o BPM, o un proyecto combinado de integración que contemple tanto software, hardware, redes y servicios por ejemplo. Todos estos proyectos por más que puedan formar parte de lo que se denominan proyectos IT, tienen cada uno particularidades, complejidades y conocimientos muy diferentes y de diverso tipo (no es lo mismo implementar un Data Warehouse que hacer un desarrollo Web, por más que los dos puedan ser complementarios).

En segundo término cuando hablamos de Gerente de Proyecto hacemos mención a la persona responsable de alcanzar los objetivos del proyecto. La dirección de proyectos conforme el PMI es la aplicación de conocimientos, habilidades, herramientas y técnicas a las actividades de un proyecto para satisfacer los requisitos del mismo. La dirección de proyectos se logra mediante la aplicación e integración de los procesos de dirección de proyectos de inicio, planificación, ejecución, seguimiento y control, y cierre. Comprender y aplicar lo que se denominan “buenas prácticas” no es suficiente por sí solo para una dirección de proyectos efectiva. Para eso se requiere que el equipo de dirección del proyecto comprenda y use los conocimientos y las habilidades correspondientes a, por lo menos, cinco áreas de experiencia:

• Fundamentos de la Dirección de Proyectos (por lo general los descriptos en la Guía del (PMBOK®) que comprenden: Definición del ciclo de vida del proyecto, Los cinco Grupos de Procesos de Dirección de Proyectos, y las nueve Áreas de Conocimiento

• Conocimientos, normas y regulaciones del proyecto mismo, en el caso de IT el desarrollo o la ingeniería de software o algún tipo específico de ingeniería, conocimientos de contrataciones, desarrollo de nuevos productos, conocimiento de industrias o servicios, conocimientos tecnológicos, etc.

• Comprensión del entorno del proyecto, todos los proyectos se planifican e implementan en un contexto social, económico y ambiental y tienen impactos positivos y negativos deseados y/o no deseados. El equipo del proyecto debe considerar el proyecto en el contexto de su entorno cultural, social, internacional, político y físico.

• Conocimientos y habilidades de dirección general que proporciona los fundamentos para desarrollar habilidades de dirección de proyectos y a menudo es esencial para el director del proyecto. En cualquier proyecto, es posible que se requieran habilidades relativas a una gran cantidad de temas generales de Management [1].

• Y finalmente las denominadas “Habilidades Interpersonales” que incluyen:

  • Comunicación efectiva. Intercambio de información
  • Influencia en la organización. Capacidad para “lograr que las cosas se hagan”
  • Liderazgo. Desarrollar una visión y una estrategia, y motivar a las personas a lograr esa visión y estrategia
  • Motivación. Estimular a las personas para que alcancen altos niveles de rendimiento y superen los obstáculos al cambio
  • Negociación y gestión de conflictos. Consultar con los demás para ponerse de acuerdo o llegar a acuerdos con ellos
  • Resolución de problemas. Combinación de definición de problemas, identificación y análisis de alternativas, y toma de decisiones

Competencias de un PM IT

Hasta aquí los requisitos y cualidades del PM son los mismos para cualquier tipo de industria, pero por ser IT la industria más destacada en el plano de innovación y complejidades obliga al PM estar al tanto de ciertos conocimientos técnicos, el empleo de otro tipo de herramientas y hasta de procesos, para lograr ser efectivos en la implementación de los proyectos. La necesidad de estar al día con los cambios tecnológicos, el hecho de que estamos trabajando con un team de profesionales muchas veces denominado equipos autogestionados, la complejidad de los proyectos, la demanda del “time to market” y la aparición de las denominadas “metodologías ágiles”, son los aspectos que marcan las diferencias más destacadas entre los PM de IT con el resto.

Al margen de estas consideraciones, siempre existirán capacidades denominadas “blandas” o “arte” y capacidades “duras” o “ciencia” definidas por las áreas de conocimiento del PMBOK. El PM necesita una mezcla de ambas, por un lado liderar (arte) que requiere de una fuerte capacidad de comunicación, visión, empleo de habilidades interpersonales, motivación, etc, y por otro gerenciar (ciencia) que requiere de dirigir y conocer la metodología a aplicarse, sus herramientas y una fuerte capacidad de análisis y resolución de problemas. A modo de resumen las competencias de un PM IT se pueden agrupar en :

People Skills: la más importante de las competencias de un PM es su habilidad para comunicarse con los demás incluyendo al grupo de trabajo, el cliente, el sponsor, los stakeholders y su propio jefe. Aquí las habilidades de liderazgo natural, la persuasión, la escucha activa, habilidades de negociación, la asertividad, la inteligencia emocional, la empatía y la motivación juegan un rol fundamental para el éxito del proyecto. La nueva versión del PMBOK® incluye ahora un anexo aparte (muy resumido) sobre las “habilidades interpersonales” del gerente de proyecto, aplicables también a un PM IT. El PM que trabaja en proyectos de IT tiene por lo general un grupo de trabajo muy particular en cuanto a sus necesidades, conocimientos y comportamientos, por lo general estamos hablando de profesionales experimentados y es muy frecuente trabajar con equipos de “alto desempeño” en donde el rol del PM debería ser más de facilitador que gerente, tratando de que su gente obtenga los recursos necesarios, y eliminando los obstáculos o problemas cuando se presenten. En las metodologías adaptativas o ágiles se le da mucha importancia a este aspecto. Otra habilidad importante es la de dirigir grupos virtuales, aspecto que hoy en día se da mucho en la práctica como los famosos proyectos 24 hs o “follow the sun”. La dispersión geográfica y horaria en los proyectos los torna muy dificultosos, y mucho más aún si se ha escogido una metodología ágil en donde la comunicación cara a cara es esencial. Cuando nos encontramos con proyectos de este tipo deberíamos tener estrategias especiales para saber cómo manejarlos dado que no estamos en contacto directo con todos, ni podemos controlarlos las 24 horas del día. El spam management deberá ser más alto, tendremos que aplicar técnicas de control a distancia, y las comunicaciones y tecnologías pasan a ser un factor vital. La Web 2.0 en todas sus variantes es un “must” en estos casos y se recurre al uso de muchas herramientas y técnicas que ella nos ofrece para una mejor implementación y control del proyecto.

Metodología y Procesos: un gerente de proyecto debería seguir y adherirse a una metodología y procesos formales para la implementación de un proyecto. En este punto son esenciales el conocimiento del PMBOK® sus procesos y áreas de conocimiento, tener claro cual será el Software Development Life Cycle a seguir (SDLC) iterativo, incremental, espiral, waterfall, etc., los propios procesos y procedimientos de la organización, los procesos y estándares a utilizar en el control de calidad del producto (auditorías, inspecciones, testeos, revisiones técnicas previas formales, etc.), las métricas de medición a aplicarse, los reportes y controles periódicos a realizar y publicar, y en general todos los métodos cuantitativos de administración de proyectos. Un PM IT deberá aplicar además conocimientos adquiridos de otras fuentes y bibliografía especializada de IT que complemente a dicha guía tal como el SWEBOK®, procesos de desarrollo y testeo de software, conocer acerca de normas de calidad (ISO, CMMI, ITIL, etc.) y cualquier otra metodología específica relacionada con el proyecto mismo (por ejemplo Metodología para la implementación de un Data Warehouse). En este punto es donde las diferencias con el manejo de proyectos de otras industrias se manifiesta de manera más abierta. Metodologías nuevas para el manejo de proyecto (Scrum, Crystal, RUP, XP, etc.) surgieron para llevar adelante proyectos con características muy particulares, que de acuerdo a sus seguidores, no podrían llevarse a cabo con metodologías tradicionales (PMBOK). Una explicación detallada sobre las metodologías ágiles y su diferencia con la tradicional del PMI es cubierta en otro artículo aparte debido a la importancia y controversias sobre el tema [2].

Conocimientos Tecnológicos: El conocimiento de la tecnología sobre la que se trabajará en el proyecto, tanto software como hardware, provee al PM de IT de un plus adicional. La pregunta que me realizan siempre es hasta cuanto uno debe conocer de la misma. No hay una respuesta única, a mi criterio dependerá del cliente, tipo de proyecto y duración del mismo. Por ejemplo un proyecto corto de desarrollo web requeriría fuertes conocimientos tecnológicos dado que no hay tiempo suficiente para ir adquiriéndolo en la marcha. En otros casos, sobre todo los proyectos más largos, primaría un poco más el conocimiento del negocio que el tecnológico. No estamos diciendo aquí que el PM debe ser un experto tecnológico (para ello tendrá el personal adecuado) pero debería tener la suficiente experiencia como para poder dialogar con el cliente y su grupo, conocer conceptos básicos acerca de Hardware (ej: diferencias entre servidores blade o rackeable), Software (ej: sistemas operativos, lenguajes orientados a objetos, bases de datos, etc.), Redes y Telecomunicaciones. Siempre es importante y útil conocer sobre lo que vamos a gerenciar y estar al tanto de los últimos avances tecnológicos si es que estamos trabajando como PM en la industria de IT.

El PM y su grupo de trabajo

Al margen de estas características que deberá usted tener o mejorar si es PM de IT, estará de acuerdo conmigo en que en casi todos los proyectos usted se encontrará con dos tipos de recursos/roles fundamentales además de los clásicos analistas, programadores, testers, etc. que normalmente figuran en todos los proyectos. Uno es el analista de negocio o el SME de los aspectos del negocio del cliente, por ejemplo un especialista en telcos, un especialista en finanzas, un especialista en el negocio de retail o manufactura, etc. Esta persona es el nexo más importante entre el objetivo de negocio del proyecto y las características técnicas de su implementación. Es el que trabajará fundamentalmente en la recolección y entendimiento de los requerimientos y parte del análisis y diseño de la solución. Esta persona es la que dialoga no sólo con los usuarios sino además con el sponsor y el top management para entender claramente cómo trabajan, cómo son sus procesos y sus necesidades. Los analistas de negocio tienen su propio lenguaje e incluso su propio BOK (ver el BABOK del IIBA una guía muy interesante y completa).

Por otro lado vamos a encontrarnos con el Arquitecto del Sistema o Technical Leader que es el cerebro que diseñará y liderará el desarrollo del proyecto desde el punto de vista técnico. Es el SME de los aspectos de tecnología, arquitectura, hardware y software y poseen también su propio lenguaje y sus propios BOK’s (SWEBOK, EABOK, SEBOK, etc). El definirá los modelos de diseño, objetos de datos, las bases de datos, las interfases y módulos, etc. en definitiva la arquitectura técnica sobre la que se asentará nuestro proyecto. El proyecto cuya solución de negocios y necesidades lo conoce perfectamente el Analista de Negocio, luego se plasma en un modelo de arquitectura de sistemas que es conocido perfectamente por el Arquitecto de Sistemas. Siendo asi es frecuente que el Sponsor y el top Management hablen directamente con ellos en muchos casos, dejando de lado su participación como PM. El problema consistirá en que usted debe dejar siempre claro que el “accountability” del proyecto es suyo como PM. El PM es quien debe tomar las decisiones finales, negociar y de alguna forma liderar a todo el grupo de trabajo, haciéndole saber al cliente que si bien existen recursos con mayores conocimientos que él, la comprensión total del proyecto y el éxito o fracaso serán su entera responsabilidad.

Delivery vs. Sales

En mis cursos de Project Management en general siempre señalo las diferencias que existen entre estos dos departamentos y los problemas que acarrea. Es interesante observar (al menos en mi experiencia personal) cómo las organizaciones de IT de todo tamaño organizan en forma separada el área de ventas del área de servicios. Estos silos departamentales pueden provocar en algunos casos serios problemas. Departamentos que se suponen deberían trabajar juntos y en armonía para hacer crecer a la organización tienen muy poca o ninguna comunicación entre ellos. Cuando la sinergía cae, aumenta el costo y la ineficiencia. Esto es muy común en la industria de IT entre los departamentos de ventas y delivery o servicios, que aunque en la práctica tienen funciones diferentes no podrían funcionar aislados o independientes. Ventas necesita del PM para llevar a cabo el proyecto y mantener al cliente satisfecho, el PM necesita de ventas para obtener proyectos que manejar. La discordia o desentendimiento de estas funciones puede provocar:

• Baja calidad del producto o servicio
• Daño en la relación con el Cliente
• Foco en promesas de rápidas ventas sin medir consecuencias
• No involucración conjunta de ambos teams en la pre-venta
• Escasa comunicación entre los departamentos

Para evitar este tipo de problemas y muchos otros más, los profesionales de marketing y de servicios (PM’s) necesitan adoptar las competencias de la gente más habilidosa de ambos lados. Project managers y ventas deberían ser competentes en trabajar en team, garantizando el éxito del proyecto y asegurando la satisfacción del cliente.

Los PM pueden aprender sobre conocimientos del negocio, habilidad interpersonal y de comunicaciones que son virtudes muy importantes en todos los vendedores, mientras que estos pueden aprender sobre conocimientos de metodologías, cronogramas, riesgos y determinación del alcance en proyectos. Esto dependerá fuertemente de la organización y del top management que alienten dicha relación, tanto como de cada individuo en particular quienes deberían comprender que ambos tienen fortalezas y debilidades. Los PM como la gente de ventas deberían desafiarse unos a otros de manera positiva y entender la importancia del desarrollo profesional y personal de cada uno. Como resultado de una buena sinergía la organización tendrá un departamento de ventas que comprenda sobre la complejidad de la implementación de los proyectos y PM’s con una mentalidad de time-to-market y relacionamiento con el cliente.

El Gerente de Proyecto IT Ideal

Las organizaciones suelen entrar en un dilema cuando tienen que reclutar un gerente de proyectos de IT. ¿Deben buscar alguien que posea habilidades técnicas o alguien con un deslumbrante poder interpersonal ? Sobre esto hay todo un debate y por lo general la decisión es muy particular dependiendo de la empresa, el tipo de proyecto y que se busca como relevante en el perfil del gerente de proyecto.

Por lo general la mayoría de las personas que son expertos en tecnología no quieren manejar a la gente, más bien, lo que desean es poner sus manos en la programación, ingeniería, análisis o investigación. Un típico o tradicional gerente de proyecto, por el contrario, quiere ver los proyectos finalizados a término, independientemente de la tecnología que está involucrada.

Los gerentes de proyecto, por su propia naturaleza, deben tener buenas habilidades de comunicación. Hasta hace poco, muchas empresas no requerían de habilidades de alto nivel técnico en los mismos. De hecho hay un montón de puestos de trabajo para los administradores de proyectos que no necesariamente requieren de una formación técnica. (roles de negocio). Si bien es importante para los gerentes de IT tener suficiente conocimiento básico sobre los procesos de IT y la tecnología, sobre todo deben ser capaces de manejar a la gente. Tienen que asegurarse de que los miembros del equipo pueden hacer lo que se necesita de ellos y liderarlos adecuadamente.

Por otro lado están los que piensan que las organizaciones no deberían ni siquiera considerar la contratación de alguien que no tiene experiencia en IT. Un gerente de proyecto IT que no posee la capacidad técnica necesaria pueden representar un riesgo enorme para la organización. El gerente de proyecto que se encuentra desafiado por la tecnología, está a merced de sus recursos (desarrolladores, programadores, arquitectos) para supervisar los aspectos más sofisticados de un proyecto, situación esta que significativamente puede socavar su autoridad. La falta de comprender completamente los requisitos técnicos de un proyecto puede dar lugar al fracaso del mismo. Para los que piensan asi, el hecho de que el candidato hay transitado previamente una posición de base técnica y luego tomar una posición más gerencial, sería la situación ideal.

Muchas veces todo esto se reduce simplemente a quién es el que está contratando. Hay dos tipos de personas o departamentos y que tienden a tener puntos de vista radicalmente diferentes sobre lo que es un candidato ideal. Los gerentes de línea, que son directamente responsables del trabajo, tienden a ser mucho más interesados en una persona con logros anteriores, experiencia, trayectoria y donde fue capaz de demostrar su liderazgo y el éxito en los proyectos. Por otro lado, los departamentos de recursos humanos, tienden a ser más inclinados a buscar las habilidades de IT que son más fáciles de identificar en los CV’s, lo que puede crear un abismo entre el tipo de director de proyectos que mejor se adapte a la posición y el que se percibe como impresionante sobre el papel.



Si bien el departamento que tiene la necesidad interna de un gerente de proyecto de IT es el responsable final y generalmente otorga mayor valor en el conocimiento tecnológico en comparación con las habilidades interpersonales, debido a que en la mayoría de las organizaciones, los recursos humanos es una parte importante del proceso de contratación, los candidatos debe ser capaces de transmitir su valía a alguien en ese departamento, quien también se interesa por el perfil sicológico y social del candidato. Al final, todo resulta en una ecuación complicada donde los candidatos ideales son cada vez más difíciles de encontrar.

En definitiva se debería tener en cuenta que mientras que las habilidades técnicas se pueden aprender en el aula y en el trabajo, ninguna cantidad de educación puede preparar a un candidato en hacer la transición desde una posición de carácter estrictamente técnico a un papel más gerencial.



Esta página ha sido calificada como:
Califica esta página:   

Temas relacionados:
Siete razones para pertenecer a la elite de los PMP®

¿Gerentes o Líderes?

+

Qué opinan nuestros lectores… ( Comparte también tu opinión )

 

oscar trujillo dijo el 20 Agosto de 2014:
Cordial saludo, Quisiera saber que son los CIO's y gerente de proyecto IT.

muchas gracias.

carlos rodriguez dijo el 28 Mayo de 2014:
esto es lo que uno tiene que tener en cuenta siempre



Comparte tu opinión
Los campos marcados con * son obligatorios.


*Nombre:
Correo:
Esconder mi dirección
*Texto:
 

.
.
Quienes somos I Base de conocimiento I Apoyo y servicios profesionales I Carrera y desarrollo profesional I Material de apoyo I Productos y souvenirs I Comunidad I Contacto I Aviso de privacidad
© LiderDeProyecto.com - Todos los derechos reservados. Capability Maturity Model® y CMM® son marcas registradas en la Oficina de Patentes de los EUA por el Software Engineering Institute (SEI) de la Universidad Carnegie Mellon®. CMM® IntegrationSM, IDEALSM y SCAMPISM son marcas de servicio de la Universidad Carnegie Mellon. PMI®, PMBOK® Guide, OPM3®, CAPM® y PMP® son marcas registradas (en EUA y otos países) del Project Management Institute, Inc. MDA®, BPMN®, SysML®, MOF®, OMG® y UML® son marcas registradas en los EUA y en otros países por el Object Management Group. Microsoft® es una marca registrada en los EUA y en otros países; Microsoft Office, Microsoft Excel y Microsoft Project son productos propiedad de Microsoft Corp. Enterprise Architect es un producto propiedad de Sparx Systems, Australia. RUP® es una marca registrada por IBM Corp.