La motivación en el trabajo (y II)

Segunda y última parte del artículo La motivación en el trabajo. puedes consultar la primera parte.Es fácil identificar aquello que amenaza con quitarnos la ilusión. Sin embargo, la pregunta que deberíamos hacernos es cómo podemos combatir el desánimo y qué elementos debemos cuidar para mantener la (des)motivación a raya. Cuando hay elementos en nuestra contra lo suficientemente importantes como para desmotivarnos, también hay una serie de razones por las que seguir adelante. Ésta es mi lista de motivos por los que trabajar motivado cada día:

  • Compromiso moral. Hacer un buen trabajo tiene un componente moral importante, ya que no hay mayor motivador que una conciencia de hierro.
  • Novedades. Encontrar nuevos retos es la mejor medicina para la falta de motivación. A veces es posible, conservando el puesto, asumir nuevas funciones y participar en nuevos proyectos.
  • Motivación a corto vs motivación a largo plazo. Si los grandes retos ya no suscitan el interés de antaño, si aquel horizonte a varios años vista se acerca peligrosamente, si nuestra perspectiva de futuro ya no es tan alentadora… la única forma de continuar motivado es cambiar nuestra percepción sobre el trabajo y el ambiente que nos rodea. Y para ello lo más sencillo es centrarnos en los detalles, las cosas pequeñas, los objetivos a corto plazo frente a las metas lejanas. En definitiva, trabajar en las pequeñas recompensas diarias. Esto implica, sin embargo, perder la visión estratégica del trabajo, por lo que sólo puede ser una medida temporal.
  • Rodearse de los mejores. En la vida hay muchas personas tóxicas: trepas, vagos, vendedores de humo, consentidos, victimistas, etc., especialistas en consumir nuestra energía sin aportar lo suficiente. Pero hay muchas más personas de honor, profesionales que sacan adelante los proyectos con humildad y esfuerzo. Es la colaboración con esas personas y el apoyo mutuo lo que en muchas ocasiones hace que merezca la pena seguir trabajando como el primer día.

Hay que ser consciente de que la falta de motivación y el desánimo son enemigos a las puertas, aguardando su oportunidad para vencernos. Si todo lo anterior no funciona quizá hayamos caído en un punto sin retorno, en el despido interior. En tal caso, seguramente, procede un cambio.

La motivación en el trabajo (I)

Ésta es la primera parte de un artículo que se centra en lo más importante de una empresa, un proyecto, una familia o un equipo de fútbol: las personas; y con ellas sus motivaciones y desmotivaciones, las decisiones que torpedean nuestra línea de flotación anímica y algunos consejos para encontrar la motivación necesaria para trabajar cuando el entorno se corrompe. Todo está condimentado con mi experiencia, las alegrías y los sinsabores de mis últimos años de trabajo, por lo que este artículo seguramente tiene un tinte más personal que otros.

Lo que importa y lo que no

La teoría de la motivación de Frederick Herzberg, o teoría de los dos factores, trata de explicar cómo nos comportamos en el trabajo atendiendo a dos tipos de elementos: los que nos motivan y los que no. El planteamiento de dos factores se puede resumir como sigue:

  • Factores de motivación. Son elementos que generalmente causan satisfacción al trabajador. Ejemplos: posibilidad de promoción, reconocimiento, responsabilidad…
  • Factores de higiene. Son elementos necesarios pero no suficientes para motivarnos. Su déficit causa desmotivación e insatisfacción, pero a partir de un nivel mínimo su incremento no tiene efectos destacables en la motivación del trabajador. Ejemplos: espacio de trabajo, remuneración, los llamados beneficios sociales…

Desmotivaciones

La de Herzberg es sólo una de las múltiples teorías que buscan explicaciones a nuestra conducta en el trabajo. Todos hemos encontrado piedras en nuestro camino, cosas que no resultan agradables, que nos pueden desanimar y sobre las que hay que estar alerta para que no mermen nuestro rendimiento ni estado de ánimo. Éstas son las principales causas de desmotivación que he podido observar a lo largo de mi experiencia laboral; todas encajan perfectamente en la categoría teórica de los factores de motivación:

  • La falta de compromiso. El equipo es la base de trabajo y la falta de implicación, de compromiso de un compañero es un elemento realmente desalentador. Especialmente cuando se ponen medios suficientes para revertir la situación pero no se logra despertar la más mínima iniciativa porque la indolencia y la actitud de “balones fuera” es superior. Es típico de personas que ya están fuera del trabajo aunque no se hayan marchado todavía.
  • La falta de autoridad. La gestión de equipos, la comunicación con los stakeholders o interesados, la dirección de un proyecto… las tareas de responsabilidad en general, requieren una autoridad que se obtiene con el trabajo y el respeto (véase auctoritas), pero también con la facultad para ejercer labores de dirección, derivada directamente del puesto que se ocupa (véase potestas). Ésta última se puede ver limitada por quienes no saben delegar tareas eficazmente, lo cual es uno de los principales inconvenientes que los mandos intermedios encuentran en su quehacer diario.

Por qué es importante planificar la llegada de un nuevo miembro al equipo

Cuando se detecta la necesidad de contratar a una persona son muchos los procesos que, formal o informalmente, se disparan en la empresa. A menudo se dedican grandes esfuerzos al proceso de selección, considerando de vital importancia fichar a quien mejor cumple con los requisitos del puesto y el resto de condicionantes (económicos y de otro tipo). Sin embargo, no siempre se valora suficientemente el proceso de incorporación, es decir, la planificación de lo que ocurre inmediatamente después de contratar a un empleado.

Todo el mundo recuerda su primer día de trabajo. Para bien o para mal, las primeras impresiones tienen un impacto elevado y se retienen para siempre. Por muchas semanas, meses, años que transcurran, la imagen que se tiene de la empresa, el equipo, el director del proyecto, etc., permanece fuertemente condicionada por su papel en aquellos primeros momentos. Por tanto, parece conveniente estar preparados para recibir a un nuevo miembro del equipo, y esto no ocurrirá hasta que se le conceda al proceso de incorporación la importancia y el formalismo que merece. Por ejemplo, desarrollando lo que podría denominarse plan de incorporación de personal. Algunos de sus beneficios son los siguientes:

  • Proteger y mejorar la imagen de la empresa, el equipo y el proyecto.
  • Evitar consecuencias negativas a largo plazo.
  • Contribuir a la retención de personal.
  • Minimizar el tiempo de aprendizaje.
  • Favorecer la adaptación a la cultura local.
  • Crear un primer vínculo con el empleado, que es importante y merece esa dedicación.

Cómo debe elaborarse un plan de incorporación de personal depende de la empresa, el equipo y el proyecto. En algunas organizaciones el departamento de recursos humanos cuenta con un plan y, con mayor o menor detalle, lo pone en práctica con cada incorporación. Estas actuaciones suelen incluir explicaciones sobre el funcionamiento general de la empresa, la cultura de la organización, los espacios comunes, algunas presentaciones informales y otras cuestiones transversales. Aunque esto pueda ahorrar esfuerzo al director de proyecto, cada equipo de trabajo acaba desarrollando con el tiempo su propia cultura local, por lo que es indispensable elaborar un plan de incorporación a nivel de equipo y proyecto, algo que en muchas ocasiones no se contempla. Es por ello que se puede estudiar cómo elaborar el plan y cómo documentarlo (sistemas de información, procesadores de texto, hojas de cálculo, correo electrónico, papel…), pero no se trata de un asunto crítico: lo fundamental es, como casi siempre, tener un plan y aplicarlo con rigor.

La importancia estratégica de la PMO y algunos errores comunes

Este post es una continuación del artículo: La Oficina de Dirección de Proyectos (PMO) y sus 10 principales atribuciones

La creación de una oficina de dirección de proyectos o PMO es una cuestión de importancia capital para la organización, y para garantizar su buen funcionamiento es necesario trabajar en múltiples frentes. Sin embargo, lo fundamental es entender el carácter estratégico y transversal del que esta unidad debe dotarse, y que ha de tener su reflejo en cada una de las decisiones que se tomen. De mi experiencia con las PMO puedo extraer algunas consideraciones para potenciar su visibilidad y relevancia, y evitar algunos de los errores más comunes:

  1. Autoridad. Una PMO sin autoridad realizará un noble intento por marcar las guías en materia de dirección de proyectos, cuestiones técnicas, políticas, coordinación entre unidades, etc., pero acabará convertida más en un estorbo que en una ayuda. Con la PMO sucede lo mismo que con la figura del director de proyecto: si no se explicita correctamente el nivel de autoridad de la PMO, y si éste no es suficiente, cualquier intento por establecer metodologías de trabajo o aprovechar sinergias será visto por los equipos de proyecto como un intento de imposición o una intromisión en sus asuntos, generando el correspondiente rechazo e impidiendo la construcción de relaciones de confianza y colaboración.
  2. Responsabilidad. Si la PMO cuenta con las atribuciones necesarias y la autoridad suficiente para ejercerlas, es de recibo reconocer su parte de mérito y de culpa en el buen o mal término de los proyectos desarrollados bajo su área de influencia. En una organización con una PMO fuerte no todos los fallos son responsabilidad del project manager ni el éxito tiene un solo padre.
  3. Impacto. Las medidas puestas en marcha por la PMO afectan positiva o negativamente a todos los proyectos bajo su ámbito de influencia, y en muchas ocasiones las consecuencias de tales decisiones se arrastran durante años. Por ello, es fundamental realizar un análisis de alternativas y, en la medida de lo posible, probar en ámbitos reducidos la eficacia de las medidas que se pretende adoptar. La técnica del prototipo es tan útil aquí como en cualquier otro ámbito. Nunca se debe subestimar el impacto de las nuevas medidas a implantar en el desarrollo de proyectos en curso, y siempre es aconsejable incorporar y consultar previamente a los principales interesados.
  4. Diversidad. No todos los proyectos, departamentos o equipos de trabajo son iguales. Si es admirable la tarea de homogeneizar procedimientos y sistemas de trabajo, más admirable aún es respetar y comprender las particularidades de cada proyecto, y eso pasa por hacer el esfuerzo de conocerlos. Ignorar este punto supone que las decisiones de la PMO pueden acabar perjudicando gravemente a algunos proyectos mientras que otros salen beneficiados, sin lograr realmente el objetivo propuesto. Para evitar estos desagradables escenarios, es conveniente siempre no tomar decisiones a la ligera ni con carácter exclusivamente técnico o metodológico, sino valorar distintas alternativas y, en cualquier caso, priorizar los proyectos en función de su contribución a los objetivos del negocio.
  5. Tecnología. La decisión de adoptar una tecnología o un marco de desarrollo nuevo siempre encuentra las resistencias habituales al cambio, tanto en los desarrolladores como en los usuarios del producto-software. En el ámbito de las PMO de proyectos TIC he podido comprobar cómo la elección de las tecnologías a utilizar en el proyecto, realizadas únicamente por técnicos, a espaldas del negocio, y sin conocer siquiera las características de algunos de los proyectos afectados (es decir, sin el suficiente rigor) acaban perjudicando gravemente el desarrollo de los proyectos más importantes para el negocio. Ojo con la elección de las tecnologías de desarrollo porque si algo sale mal no es sencillo ni barato cambiar el entorno tecnológico y las malas decisiones se pueden arrastrar a lo largo de la vida completa del proyecto.
  6. Metodología. Otro mal ejemplo de mi experiencia con una PMO fue la creación ad hoc de metodologías de desarrollo y su posterior implantación en proyectos ya en marcha. Pero, ¿metodologías creadas ad hoc para quién? Buena pregunta cuando los proyectos de la organización son muchos y distintos. En el caso que nos ocupa, las metodologías de desarrollo inventadas (a menudo son un refrito de varias muy diferentes) y la propuesta tecnológica escogida sin mucho criterio encajaban en la mayoría de proyectos pequeños en que se implantaban, pero no en el único proyecto con aportación significativa al negocio y de tamaño mucho mayor, con el consiguiente fracaso de la medida, que acabó en el olvido.
  7. Estrategia. Lo anterior son dos ejemplos de planteamientos incorrectos y mal ejecutadas en una PMO, consecuencia de una visión centrada en el día a día, las miras a corto plazo, la falta de proximidad con los equipos de proyecto, el desconocimiento de la realidad y la marcha de algunos de los proyectos afectados, la falta de alineamiento con el negocio y, por tanto, la falta de pensamiento estratégico. El pensamiento estratégico debe ser la marca característica de una PMO, aquello que la lleva a tomar decisiones que traigan impacto y beneficio en el largo plazo, y que tengan en cuenta la visión global y conjunta de los proyectos y el apartado del negocio. Recuérdese:

La PMO debe ser una oficina de liderazgo, no de soporte.

La Oficina de Dirección de Proyectos (PMO) y sus 10 principales atribuciones

Al revisar la estructura de una empresa, o el registro de interesados (stakeholders) de un proyecto, es sencillo identificar el papel y las funciones de algunas de las unidades más habituales en cualquier organización; por ejemplo, el departamento de finanzas, el servicio de informática o el equipo de comerciales. Otras unidades de la organización no son tan conocidas Y en ocasiones ni siquiera tienen la visibilidad que mereces. Tal es el caso de la Oficina de Dirección de Proyectos o Project Management Office (en adelante, PMO), que resulta ser generalmente un departamento transversal en la organización dedicado a coordinar la dirección de proyectos a su cargo.que resulta ser generalmente un departamento transversal en la organización dedicado a coordinar la dirección de proyectos a su cargo.

El Project Management Institute aporta una definición más formal en su guía PMBOK:

A project management office (PMO) is a management structure that standardizes the project-related governance processes and facilitates the sharing of resources, methodologies, tools, and techniques. The responsibilities of a PMO can range from providing project management support functions to actually being responsible for the direct management of one or more projects.

En muchas empresas o Administraciones Públicas no existe la Oficina de Dirección de Proyectos. En organizaciones pequeñas casi siempre es presincidble, y cobra mayor importancia conforme aumenta el tamaño y la complejidad de la organización y los proyectos. En organizaciones grandes sus funciones a veces se reparten entre la alta dirección, los directores de proyecto, los técnicos y los mandos intermedios. Lo cierto es que no existe una modelo correcto o consensuado para diseñar y constituir una PMO, y en la práctica su implementación difiere completamente de una organización a otra. Aún así, lo habitual es que esté formada por varias personas cualificadas en dirección de proyectos y perfectamente al tanto del rumbo del negocio.

En el proceso de implantación de una PMO es muy recomendable abordar con decisión algunas cuestiones de tipo organizacional de las que dependerá el éxito de su trabajo. Por ejemplo, es fundamental que la PMO nazca con una misión y unas competencias claras, con la autoridad necesaria y el respaldo de la alta dirección. La cuestión de la autoridad -y esto es igualmente válido para directores de proyecto y programa- debe quedar completamente resuelta y explícita, especialmente si se trata de organizaciones no orientadas a proyectos, donde adquiren mayor dificultad todas las tareas transversales, como la reingeniería de procesos, la gestión de proyectos y la modificación de grupos de trabajo.

Las 10 principales atribuciones de una PMO

Las funciones que puede desempeñar una PMO son muchas y casi todas de carácter transversal. Su papel puede llegar a ser determinante para que los proyectos en marcha lleguen a buen puerto, lo cual afecta inevitablemente al apartado del negocio. Es por ello que, insistiendo en lo anterior, resulta imprescindible definir y comunicar con claridad meridiana los asuntos de los que se encargará esta unidad, así como la autoridad que se le otorga para cumplir su misión. La PMO será ineficiente si su papel no está claramente especificado y delimitado.

Algunas de las atribuciones habituales de una PMO:

  1. Dirección de proyectos. Asumir la dirección en exclusiva de determinados proyectos o programas para los que no se contratan nuevos directores. Siempre que lo he visto se ha tratado de proyectos de tamaño reducido.
  2. Alineamiento de proyectos y negocio. Poner énfasis en la supervisión, planificación, priorización, ejecución y cancelación de proyectos en función de los planteamientos estratégicos de la organización. Una de las funciones de la PMO es velar porque comportamientos y procedimientos desarrollados dentro de los distintos proyectos concuerden siempre con los objetivos del negocio.
  3. Evaluación de propuestas. Colaborar en la evaluación de potenciales proyectos, analizar su viabilidad y su conveniencia desde el punto de vista del negocio y participar así en el proceso de aprobación o rechazo.
  4. Coordinación. La PMO asume frecuentemente el rol de coordinador de directores de proyecto, programa, portafolio, alta dirección, patrocinadores y otros interesados.
  5. Consultoría. El project manager encuentra en la PMO a un grupo de expertos en dirección de proyectos (normalmente, otros project managers) a los que pedir consejo, plantear problemas y trasladar sugerencias relativas a las particularidades que surgen en su proyecto. Aconsejar en buenas prácticas de dirección de proyectos dentro de los criterios de tiempo, coste y calidad aceptables es una de las principales atribuciones de una PMO, siendo de especial utilidad sus aportaciones a la gestión del cambio y la integración. Por otro lado, es frecuente ampliar la consultoría a ámbitos técnicos, muy típico de las PMO de organizaciones TIC.
  6. Configuración. Proporcionar metodologías, plantillas, políticas, herramientas informáticas, tecnologías de desarrollo, etc.
  7. Garantizar el acceso a la información. Actuar como punto de contacto y gestionar el acceso a la documentación histórica y las lecciones aprendidas, así como a la información de proyectos aún no cerrados.
  8. Formación. Diseñar y dirigir los programas de formación de la organización, debiendo tener en cuenta las necesidades de cualquier miembro del equipo y no centrándose únicamente en formación relativa a dirección de proyectos. En este apartado se deben considerar cuestiones de negocio, tecnologías, certificaciones, comunicación, gestión de equipos, etc.
  9. Recursos humanos. Selección de personal para nuevas incorporaciones y también análisis de perfiles para fomentar sinergias entre proyectos y movimientos de personal, logrando un mejor aprovechamiento de los recursos propios y reduciendo costes de tiempo y curva de aprendizaje de nuevos miembros del equipo.
  10. Cultura de project management. Si existe una PMO en la organización, la tarea colosal de crear una cultura de dirección y orientación a proyectos será su responsabilidad primordial y, por desgracia, casi exclusiva. Este esfuerzo por difundir y defender la implantación de buenas prácticas de dirección de proyectos debe realizarse en dos sentidos: hacia los equipos de proyecto (no sólo el project manager) y hacia los niveles directivos de la organización.

Aprender a delegar (II): 5 cosas que debes asumir cuanto antes

La delegación está en la base del trabajo en equipo y los grandes proyectos: es una herramienta útil para involucrar y motivar a otros miembros del equipo, y también es la única forma conocida de comprar tiempo. Un buen gestor debe interiorizar, asumir cuanto antes cinco cosas totalmente necesarias a la hora de delegar eficientemente

  1. Ser humilde. Hay que aceptar que uno no puede hacerlo todo, aunque sepa, y probablemente tampoco sabrá de todo. Además, en muchas ocasiones  no se trata de no estar preparado para resolver una tarea, sino de reconocer que otra persona lo puede hacer más eficientemente. Empeñarse en acometer tareas que otros realizarían mejor o en menos tiempo es a menudo una irresponsabilidad.
  2. Renunciar a algo. Quien delega debe asumir que las tareas no serán implementadas tal cual lo imaginó o del mismo modo en que lo hubiera hecho él. Dar libertad a alguien significa reconocer que siempre hay una pérdida de control o precisión, un pequeño desacuerdo. La tarea de quien delega es sentar las bases para que esa diferencia sea aceptable.
  3. Repartir bien el trabajo. En lo posible, no se debe delegar siempre en los mismos miembros del equipo. Es bueno dar oportunidades, involucrar a gente nueva y luego reconocer sus méritos. La repartición del trabajo y la transferencia de conocimiento (es decir, aprender unos de otros) fortalece el equipo.
  4. Comunicar correctamente. Se trata de transmitir clara y completamente la información que se requiere para abordar la tarea delegada, así como la forma de gestionar los resultados. En general, si no puedes explicar algo bien es que no has acabado de entenderlo. A lo mejor no es necesario entenderlo del todo, pero sí hay que tener claro en qué consiste el trabajo y cuál es el alcance. Las herramientas de comunicación son poderosas si se utilizan bien, pero pueden ser un enredo en caso contrario. No hay que ahorrar esfuerzos comunicando, aclarando, repitiendo, insistiendo, comprobando. La responsabilidad de que el mensaje se entienda es del emisor, no del receptor.
  5. Delegar de forma distinta. No siempre es posible hacerlo del mismo modo, y ello depende fundamentalmente de dos factores: las características del trabajo y la persona a quien se transmite la responsabilidad de acometerlo. En función de lo anterior se establecen diferentes niveles de autoridad y mecanismos de monitorización. Un artículo interesante: Understanding the four levels of delegation when managing people in business, que divide en cuatro niveles el alcance que puede tener la delegación de tareas.

Por último, la intervención de Martin Varsavsky en LeWeb London 2012, donde explica cómo gestiona su tiempo, y remarca: “When you delegate, you say goodbye to decision making but it’s the only way to buy back your time.

Retos de la dirección de proyectos en la Administración Pública

El día a día de la dirección y gestión de proyectos en la Administración Pública difiere con seguridad del trabajo en el sector privado. Sí, un proyecto es un proyecto, pero cuando los interesados, las prioridades del negocio, las relaciones con proveedores, las condiciones laborales, el poder, sus contrapesos y el entorno en general es tan distinto al llegar a una Administración Pública, la gestión de proyectos acaba siendo diferente también.
Son muchos los condicionantes a la hora de crear un equipo competitivo y realizar un trabajo eficiente, pero lo cierto es que hay un elemento con bastante más importancia que el resto: las personas. En mi opinión, con gente preparada, motivada y responsable es posible construir un buen grupo independientemente del entorno y los factores ambientales. He recopilado algunas de las cuestiones más peliagudas con las que en alguna ocasión he tenido que lidiar en la Administración Pública, y que afectan directamente a la planificación, ejecución y buen término de un proyecto:

  1. Definición de proyecto. La diferencia entre proyectos y operaciones se diluye y en ocasiones tiene escaso reconocimiento formal, algo a lo que en ocasiones contribuye la ausencia de fuertes objetivos de negocio con los que alinear los proyectos. Una consecuencia directa es que a menudo no existe una separación de funciones clara, de modo que las tareas de mantenimiento, el service desk y los nuevos desarrollos no se llevan a cabo en equipos diferenciados. Cuando el concepto clásico de proyecto se debilita tanto, muchos “proyectos” acaban siendo un conjunto de tareas de mantenimiento, mezcladas con desarrollos a ráfagas, que se prolongan durante muchos años y cuya fecha de fin no se vislumbra ni conoce.
  2. Organización funcional o matricial. Estas estructuras, típicas de la Administración, favorecen la aparición de departamentos estancos y de pequeñas taifas, parcelas de poder aisladas del resto. Los puestos de trabajo además van en función de escalas fijas, no adaptadas al proyecto en curso. Ello supone una complicación seria cuando el ámbito de un proyecto supera al del departamento en que se desarrolla. Es decir, cuando se requiere la colaboración de otras unidades para aportar análisis de requisitos, validaciones, identificación de riesgos, etc. Es en estos casos cuando se debe tener una clara orientación a proyectos y un liderazgo que coordine esfuerzos sobre una línea común. De no ser así, todo el trabajo asociado a proyectos con origen en otros departamentos se convierte en algo secundario, sin la debida planificación y “para cuando haya tiempo”.
  3. Burocracia. Para atajar desviaciones y corregir el rumbo de un proyecto es necesaria cierta flexibilidad; por ejemplo, a la hora de desplazar recursos. La burocratización de los procesos es una de los principales dificultades para la implantación rápida de acciones correctivas. Esto se puede comprobar con la lentitud a la hora de mover personal entre proyectos que no se consideran del mismo departamento o grupo estanco, incluso de modo temporal y para períodos cortos. Algo similar ocurre al subcontratar una parte del proyecto. Para tratar de atenuar este efecto, la dirección del proyecto debe tratar de anticipar sus movimientos todo lo que sea posible.
  4. Gestión económica. En ocasiones el seguimiento económico de un proyecto no es tan exhaustivo como debería. Para esto he encontrado diversas causas:
    • No hay una tradición larga en dirección de proyectos con metodologías de gestión profesionales.
    • El dinero se gestiona como grandes bolsas asignadas a grupos de investigación, departamentos, encomiendas de gestión, etc.
    • El hecho de que muchos proyectos arranquen sin haber cerrado completamente su ámbito, fecha de fin, recursos necesarios, etc., no contribuye a determinar un presupuesto con la precisión deseable.
  5. Decisiones. En cualquier entorno es importante comprender el mecanismo de toma de decisiones de los líderes y directivos. En una empresa es sencillo pensar en criterios más o menos evidentes como la facturación, el posicionamiento de una marca o determinados objetivos del negocio; pero cuando la cuenta de resultados no importa mucho resulta más complicado distinguir cuáles son las grandes líneas estratégicas de la compañía.
    Además, los puestos más altos son políticos, y la política en España tiende a fijarse en el corto plazo, lo cual puede llevar a la dirección estratégica a caer en modas: por ejemplo, de repente puede ser fundamental desarrollar una aplicación informática para comprar consumibles o elaborar con urgencia un plan de austeridad. Medidas fáciles y llamativas a cambio de no acometer grandes reformas estructurales. Muchas de esas decisiones, víctimas de corrientes de opinión efímeras, torpedean alegremente la planificación, ejecución y estabilidad de los proyectos en marcha.
  6. Orientación a objetivos. Una gestión eficaz de personal y de equipos de trabajo siempre apostará por la orientación a objetivos, es decir, por tres ideas básicas: dividir el trabajo en pequeñas parcelas, adquirir el compromiso de acometerlas según ciertas condiciones pactadas y evaluar el rendimiento. La organización tradicional del personal público hace necesario plantear estas cuestiones más seriamente.
  7. Meritocracia. Es otro de los pilares de la gestión de equipos, la recompensa del esfuerzo profesional mientras se actúa contra los malos resultados con medidas correctivas. La meritocracia es implantada y fomentada por los buenos directivos y es despreciada por aquellos que prefieren el amiguismo, la igualdad en la mediocridad y las decisiones fáciles. De nuevo, la rigidez en cuestiones laborales y de otro tipo de la Administración Pública dificulta (pero no imposibilita) el establecimiento de mecanismos de compensación eficaces.
  8. Funcionarios. No todos los trabajadores de la Administración Pública tienen el mismo tipo de relación laboral. El caso más evidente es el de los llamados trabajadores externos (ese “servicio” que las consultoras prestan a la Administración), cuyo día a día consiste en ser empleados de la casa y realizar correctamente su trabajo pero sin los beneficios de ser empleado público. Sin embargo, la diferencia fundamental que muchos no acaban de comprender es la que existe entre políticos y funcionarios; la difusa línea que separa a los cargos de confianza de los gestores profesionales, las funciones del Gobierno de las funciones de la Administración, el líder político del funcionario de carrera. Sin tener completamente clara esta cuestión no se puede entender, progresar, gestionar y dirigir en el mundo de la Administración Pública. Borja Adsuara lo explica muy bien en su artículo Funcionarios y políticos.

Estos ocho puntos ni representan el escenario más deseable, ni se dan todos los días, ni son todos exclusivos de la Administración Pública, naturalmente. Pero en cualquier caso no está de más conocerlos y reflexionar sobre ellos para comprender mejor las particularidades de ese entorno de trabajo.

Mis 12 consejos para aprobar el PMP

Hace años que obtuve la certificación PMP y quiero compartir algunos consejos fruto de mi experiencia, tanto en el proceso de estudio como en el propio examen:

  • Hazte miembro del PMI. Tendrás acceso a revistas, artículos, foros, las guías, multitud de webinars, etc. El descuento en la matrícula del examen compensa el pago de la cuota anual. También podrás inscribirte en un capítulo (asociaciones locales de miembros del PMI, cuota anual de $30), accediendo a más recursos, actividades y profesionales; yo soy miembro del PMI Valencia Chapter.
  • Estudia en inglés. Si tienes buen nivel, es recomendable porque hay muchos más recursos (tests, libros, foros, cursos…). Además, estudiar en un solo idioma ayuda a evitar confusiones con las traducciones y la nomenclatura. Es conveniente aprender la materia en un solo idioma, y luego revisar las traducciones si es necesario.
  • Relaciona la materia con tu experiencia. Conforme avances el estudio irás relacionando los procesos del PMBOK con los que has implementado alguna vez en tu trabajo. Estas asociaciones ayudan a retener la información y a profundizar en la guía con visión crítica. Tu experiencia laboral te ayudará a responder preguntas difíciles aplicando tres criterios básicos: código de ética, sentido común y mayor beneficio para el proyecto.
  • Reflexiona sobre las entradas, salidas y herramientas. Leerlas sin más no ayuda e intentar memorizarlas es un disparate: ¡son muchas! En lugar de eso, a la hora de estudiar (y ante preguntas directas en el examen) pregúntate siempre: ¿qué información necesitaría para desarrollar este proceso? ¿Qué herramientas podría utilizar? ¿Qué resultado obtendría?
  • Analiza bien las fórmulas. La mayoría de las fórmulas son de Earned Value Management, aunque hay alguna en otros capítulos, como el de contratación. Casi todo el mundo recomienda memorizar todas y cada una de las fórmulas, pero mi consejo es simplemente entenderlas, razonarlas y, muy importante, ser capaz de deducirlas. Es un objetivo asequible, garantiza que entiendes completamente la materia y te sacará de un apuro si la memoria falla.
  • Deja la parte de integración para el final. Aunque este capítulo aparece al principio de la guía, en mi opinión es conveniente estudiarla en último lugar, una vez que se conocen todos los procesos y se han trabajado todas las áreas de conocimiento. Este consejo se lo debo a Ángel L. Pérez, PMP.
  • Consigue material de apoyo. Recomiendo PMP Exam Prep, un libro que contiene información ampliada, ejemplos y consejos para el examen, y que además hace mucho más ameno el estudio (PMBOK es esquemático y aburrido).
  • Haz muchos tests hasta superar tu nota mínima. Es fundamental, cuantos más hagas mejor. No sabrás realmente el nivel que tienes hasta que te enfrentes a varios tests y obtengas regularmente un resultado por encima de una nota mínima razonable. En mi caso, me impuse un objetivo de 80% de respuestas acertadas.
  • Escoge bien el simulador de tests. Algunos simuladores permiten realizar tests de muchos tipos (por grupos de procesos, áreas de conocimiento, nivel de dificultad, número de preguntas, etc.), permitiendo mejorar aquellas parcelas de la dirección de proyectos en las que obtengamos peores resultados, o adaptar el test al tiempo que tengamos. Llega un momento en que no compensa seguir realizando tests con el mismo simulador, ya que aparecen bastantes preguntas repetidas; por tanto, una base de datos con pocas preguntas nos será poco útil. Yo utilicé PM FASTrack PMP Exam Simulation Software, y un par de veces SimpliLearn.
  • Haz varios ensayos generales y establece criterios de rendimiento. El examen tiene 200 preguntas y puede durar 4 horas, de modo que la fatiga o la falta de concentración pueden sorprenderte. Si puedes, haz varios tests de 200 preguntas antes del examen, controlando el tiempo. Te recomiendo establecer un umbral de rendimiento y vigilar las desviaciones. El mío fue de 1 minuto por pregunta, bastante estricto.
  • Ponte la presión que necesites. La presión me gusta, rindo bien. Comenté mi intención de preparar el examen en mi entorno personal y laboral, y animé a algún amigo a presentarse, aprobando antes que yo. En mi caso, hacerlo público contribuyó a mantener el punto de presión necesario. Mucha gente sólo desvela sus proyectos cuando tienen el éxito garantizado. Éste es un aspecto a valorar por cada cual.
  • Estudia en serio. El examen es como un proyecto, se suele decir… Planifica bien,  actualiza la planificación cada semana, estudia con regularidad y ve cumpliendo objetivos parciales. Ningún consejo es más importante que éste.

¡Suerte!

Qué es el gold plating y cómo evitarlo

El término gold plating hace referencia a una mala práctica que consiste en ampliar la funcionalidad de un producto o servicio sin un motivo claro desde el punto de vista metodológico y de gestión. La persona encargada de crear un producto le añade características que no están incluidas en la documentación aprobada, y lo hace generalmente sin el conocimiento, las indicaciones y el respaldo de la dirección del proyecto. Es un error especialmente lamentable, ya que no tiene una causa externa directa: surge en el seno del proyecto y es generado por el propio equipo. En español, se emplea a veces la traducción bañado en oro.

Cómo identificar el gold plating

Aparece generalmente en dos fases del proyecto:

  • Toma de requisitos. Sucede cuando se modifican los requisitos funcionales para introducir funcionalidad compleja que no suscita un interés real en el cliente, y que no está respaldada por un caso de negocio u otro tipo de propuesta formal. También puede ocurrir con los requisitos no funcionales, elevando los criterios iniciales de rendimiento, disponibilidad del servicio, tiempos de respuesta, etc.
  • Creación del producto. Es el caso más común, especialmente en proyectos TI, los más afectados por esta mala práctica, donde a la etapa de fabricación de producto se la denomina desarrollo. Aparece cuando el desarrollador decide por su cuenta mejorar el producto, alterando lo definido en la documentación de análisis y diseño, ampliando la casuística inicialmente contemplada para incorporar nuevas características o empleando tecnologías novedosas que complican la implementación.

Por qué es una mala práctica

No es difícil encontrar opiniones favorables, especialmente de desarrolladores que ven en esta mala práctica la oportunidad de conseguir ciertos réditos personales. He aquí algunos ejemplos frecuentemente utilizados para justificar el fenómeno, y que pueden distraernos de las verdaderas consecuencias del gold plating:

  • Al cliente le ha gustado la nueva funcionalidad. No la esperaba y ha sido una sorpresa agradable.
  • La mejora introducida ha sido una de las opciones más utilizadas de la aplicación informática.
  • La novedad técnica es bienvenida y cuenta con el visto bueno de otros técnicos.

Es conveniente dejar libertad absoluta al creador, de lo contrario se perjudica la calidad y se castiga la creatividad.Sin embargo, los efectos del gold plating son casi siempre perjudiciales y su impacto en la planificación del proyecto suele ser elevado. Quizá no sea tan evidente comprobar el precio que se paga:

  • Prioridades. El equipo permite que pase a un segundo plano el verdadero objetivo del proyecto: entregar un producto o servicio de acuerdo a los requisitos, tiempo y presupuesto acordados.
  • Decisiones. Este apartado es especialmente delicado, ya que quien incurre en gold plating acaba cometiendo dos errores. Por un lado, toma decisiones que no le competen, ya que no cuenta con el cliente ni el director de proyecto. Por otro lado, toma decisiones equivocadas: ¿era imprescindible para el cliente incluir una nueva características de la que no había oído hablar? Quizá lo más importante era la fecha de entrega, el presupuesto, la disponibilidad de recursos para otros proyectos…
  • Recursos. El gold plating es en esencia un sobreesfuerzo injustificado, y por tanto tiene una consecuencia directa: se malgastan recursos de todo tipo (horas/hombre, recursos informáticos, presupuesto, etc.).
  • Complejidad. Se añade complejidad al producto y su implementación, y ello puede revertir negativamente en tareas de documentación de análisis, diseño, requisitos, manuales, etc., así como en el mantenimiento futuro del producto o servicio.
  • Frustración. En ocasiones detrás del gold plating se esconde la intención, más o menos loable, de colgarse una medalla. No valorar con entusiasmo una funcionalidad extra puede causar frustración en ese desarrollador que, sin tener en cuenta las consecuencias anteriormente descritas, incurre en gold plating por puro perfeccionismo y cree haber realizado un esfuerzo colosal y digno de aplauso.

Estrategia para evitar el gold plating

En un proyecto hay múltiples factores que favorecen la aparición del gold plating, y por tanto la mejor estrategia es considerarlo un riesgo. Para evitarlo o para mitigar sus efectos es necesario actuar de manera continuada en cinco frentes:

  • Dirección. Establecer con claridad meridiana las líneas de trabajo y el rumbo a seguir. Una labor de coordinación deficiente puede ser causa de interminables problemas.
  • Gestión de equipos. Ingenieros y programadores no deben trabajar en solitario, hacerlo en equipo y estar sujeto a dependencias reduce el riesgo de desviaciones por gold plating.
  • Responsabilidad. Un buen reparto de roles y responsabilidades lleva implícito mecanismos de contrapeso que pueden evitar malas prácticas. La concentración excesiva de competencias dificulta la detección del gold plating.
  • Monitorización y control. Para prevenir desviaciones innecesarias es imprescindible que las tareas se deleguen correctamente. Además, evitar el gold plating a menudo exige conocimientos técnicos muy específicos, especialmente cuando se produce en la fase de desarrollo del producto. Por ello es necesario no conformarse con las explicaciones de alto nivel, sino bajar más al detalle y preguntar, indagar y aclarar.
  • Expectativas. Detrás de cada caso de gold plating siempre se esconde el mismo problema: una muy mala gestión de expectativas. Lo que el cliente espera se entiende mal y se distorsiona. Conviene por tanto llevar a cabo una buena gestión de expectativas, aclarando completamente qué está incluido (y qué no) en el alcance del proyecto, documentándolo, revisándolo y recordándolo frecuentemente.

6 razones por las que debes documentar tus proyectos

La literatura sobre dirección de proyectos está plagada de referencias a los distintos tipos de artefactos documentales (es decir, documentos) que deben producirse durante el ciclo de vida de un proyecto. El planteamiento teórico es bastante completo. La práctica revela que una gran parte de los proyectos, especialmente los relacionados con las tecnologías de la información, no se documentan suficientemente.


Resulta curioso que sea precisamente en el mundo TI donde se adolezca de falta de documentación, teniendo en cuenta que la interrupción del servicio en una organización TI puede llegar a detener por completo las operaciones de la organización. La causa de este problema radica en el menosprecio de la buena documentación y, una vez más, en la falta de rigor metodológico.

Hay cinco razones fundamentales para documentar correctamente un proyecto:

  • Importancia metodológica. Las personas que forman parte del desarrollo de un sistema o herramienta son en principio las más adecuadas para documentar los procesos, ya que han participado en su definición, creación, pruebas y puesta en producción. Sin embargo, muchos desarrolladores son generalmente reticentes a realizar tareas de documentación, por varias razones:
    • No entienden su importancia metodológica.
    • No consideran esa tarea propia de su campo de conocimiento y profesión.
    • No creen que pueda ser un mérito para su curriculum o su carrera profesional.
  • Por tanto, y dado que esta actitud negativa es bastante común, un desarrollador capaz de redactar buena documentación es un activo importante para el equipo.
  • Importancia práctica. Hay quien realmente considera útil y valiosa la documentación. A los clientes, usuarios finales y equipos de soporte les gusta la documentación, y obtienen de ella un beneficio obvio. Los directores de proyecto, generalmente con una visión más amplia y completa del proyecto, no sujeta a condicionantes técnicos exclusivamente, entienden la necesidad de documentar y fomentan las tareas de documentación desde el inicio de los proyectos.
  • Comunicación. En algunas ocasiones es posible que no todos los interesados o stakeholders de un proyecto sean accesibles para un técnico, un analista o un director de proyecto. Por ejemplo, en roles de muy alto nivel o en equipos de trabajo de gran tamaño. En estos casos, el único método de comunicación formal es la documentación.
  • Reputación. El equipo de soporte (helpdesk) debe contar con documentación, y ésta debe ser completa y estar actualizada. Lo contrario puede afectar a la resolución de problemas, dificultando o impidiendo un buen servicio de atención al cliente o usuario final. Lo más importante aquí es el posible perjuicio para la imagen del equipo o la organización.
  • Transferir el conocimiento. Las transiciones son siempre más sencillas con buena documentación. Un cambio de proveedor, cliente o de miembros del equipo puede ser mucho más costoso sin documentación. Se facilita la formación reglada y la transferencia de conocimiento, así como la reducción de contingencias por dependencias de personal.
  • Contingencias. Cuando se producen contratiempos graves, el tiempo de restauración de los sistemas y procesos es uno de los elementos más críticos. La documentación acorta los periodos de recuperación y contribuye corregir los errores de modo más eficiente.

¿Cuáles son tus consejos para documentar un proyecto?