REVISTA PROIECTUS Nº 1 by PROIECTUS

Número 1, Noviembre 2013

DIRECCIÓN DE PROYECTOS

MADE IN CANARIAS

ENTREVISTA: JEFA DE PROYECTO DE REVISIÓN TRADUCCIÓN PMBOK

DIRECCIÓN DE PROYECTOS EN CONSTRUCCIÓN DE OBRA PÚBLICA www.proiectus.es

COMO HACER REALIDAD LOS SUEÑOS DE TU ORGANIZACIÓN DIRECCIÓN DE PROYECTOS EN LA ADMINISTRACIÓN LOCAL LA FORMACIÓN: TAREA CONTINUA LA CLAVE DEL ÉXITO DE LOS PROYECTOS ISSN 2340-9363

www.proiectus.es

Número 1, Noviembre 2013

DIRECCIÓN DE LA REVISTA Iván Samuel Tejera Santana ivan.tejera@proiectus.es

EQUIPO EDITORIAL

ITPROIECTUS www.proiectus.es

COMUNICACIÓN Y DIFUSIÓN Miguel Quintanilla Eriksson Antonio Martel Rodríquez ASESORAMIENTO LEGAL Javier Rodríguez Batllori Laffitte

COLABORADORES Antonio Martel Rodríguez Eduardo Gutiérrez Bahillo Agustín Tapia Quesada Manuel Vara González Juan Carlos Falcón Portillo Davide Mazzanti Raúl Herranz Serrano Vicente González Medina Miguel Quintanilla Eriksson Monica Khiani Ashok Antonio Pedro Dorta Alonso Roberto González Yuste Claudia Fernanda del Toro Vargas

www.proiectus.es

Número 1, Noviembre 2013

¿NOS PREOCUPAMOS POR LA DIRECCIÓN DE PROYECTOS? Antonio Martel Rodríguez, PSM®

DIRECCIÓN DE PROYECTOS EN CONSTRUCCIÓN DE OBRA PÚBLICA. EL JEFE DE OBRA Eduardo Gutiérrez Bahillo

¿BLANCO O NEGRO? ¿METODOLOGÍAS PESADAS O ÁGILES? ¿SCRUM O PMBOK? Agustin Tapia Quesada

CÓMO HACER REALIDAD LOS SUEÑOS DE TU ORGANIZACIÓN Manuel Vara González

IMPLANTANDO SCRUM EN LAS EMPRESAS Juan Carlos Falcón Portillo

THE ITALIAN WAY Davide Mazzanti

¿GESTIONAS PROYECTOS TIC Y AÚN NO ERES ÁGIL? ¡MALGASTAS TU TIEMPO! Raúl Herranz Serrano, PMI-ACP®

LA FORMACIÓN: TAREA CONTINUA Vicente González Medina, PMP®

LA DIRECCIÓN DE PROYECTOS EN LA ADMINISTRACIÓN LOCAL (I): ALCANCE Y COSTE Miguel Quintanilla Eriksson

GESTIÓN DE PROYECTOS, ES IMPORTANTE SEGUIR UNA METODOLOGÍA Monica Khiani Ashok, PMP®

GESTIÓN VISUAL EN GESTIÓN DE PROYECTOS Antonio Pedro Dorta Alonso, PMP®

MIRA QUIÉN HABLA Roberto González Yuste, PMP®

LA CLAVE DEL ÉXITO DE LOS PROYECTOS Iván Samuel Tejera Santana, PMP®

ENTREVISTA: JEFA DE PROYECTO DE REVISIÓN TRADUCCIÓN PMBOK® 5 Claudia Fernanda del Toro Vargas, PMP® 3

www.proiectus.es

Número 1, Noviembre 2013

CARTA DEL DIRECTOR Bienvenid@s a este primer número de la revista PROIECTUS, publicación MADE IN CANARIAS desarrollada por y para profesionales vinculados a la Dirección de Proyectos. En febrero de 2011 creábamos en la red profesional Linkedin® el grupo PMP® Canarias, con objeto de fomentar la discusión y el debate sobre cualquier tema relacionado con la Dirección de Proyectos. Con el paso del tiempo, y a pesar de ser un grupo de carácter abierto y de difícil dinamización, muchos profesionales han querido participar de esta iniciativa, permitiendo al grupo alcanzar la cifra de 200 miembros en julio de 2013. Sin ser una cifra especialmente significativa, lo que si viene a demostrar es que hay un interés creciente de los profesionales de diferentes sectores económicos por adquirir y compartir conocimientos que permitan dirigir proyectos con eficacia y eficiencia.

Director revista PROIECTUS Iván S. Tejera Santana

En una situación económica como la actual, dónde empresas y organizaciones se ven obligadas a hacer más con menos, la figura del Director de Proyectos, con independencia del sector profesional en que desempeñe su actividad, adquiere especial relevancia y su presencia resulta fundamental para alcanzar el éxito en la consecución de los objetivos de los proyectos. Fruto de todo ello, nace la idea de poner en marcha la revista PROIECTUS, la cual, y casi de forma inmediata, es acogida con interés por los miembros del grupo, y sin cuyas aportaciones a lo largo de los últimos meses no habría sido posible la edición y publicación de la misma. Este primer número lo hemos querido dedicar a tod@s aquellos Directores de Proyectos que en algún momento de su carrera profesional han tenido contacto con el mercado canario, sin que ello suponga obstáculo alguno para que en próximos números puedan participar un mayor número de profesionales. A fin de cuentas… Canarias no es sólo sol y playa.

www.proiectus.es

Número 1, Noviembre 2013

ANTONIO MARTEL RODRÍGUEZ, PSM® Titulado en Informática y Sistemas por la Universidad Las Palmas de Gran Canaria y Professional Scrum Master. Responsable de proyectos en DESIC, compañía canaria de desarrollo software. Entusiasta de las metodologías ágiles e interesado en cualquier tema que pueda mejorar la calidad del producto entregado y el tiempo en que somos capaces de entregarlo.

¿NOS

PREOCUPAMOS

POR

Con frecuencia, cuando leo sobre Dirección de Proyectos, suelo tener la sensación de que lo que estoy leyendo me habría venido muy bien haberlo aprendido unos años atrás, cuando comenzaba a dirigir proyectos. No todo está inventado aún, pero muchos han pasado ya por las mismas situaciones por las que he pasado yo, han aprendido algo, lo han escrito en alguna parte y vaga ahora por Internet o por las estanterías de alguna biblioteca.

DIRECCIÓN

PROYECTOS?

Tengo la impresión de que en España y en Canarias en particular hay poca conciencia sobre la preparación que debe tener alguien que se dispone a gestionar un proyecto ¿sabemos a los problemas con los que nos vamos a enfrentar? ¿tenemos la formación necesaria para tratar estos problemas?

Si hubiese contado con esa información, antes de reinventar la rueda una y otra vez para terminar llegando a conclusiones a las que otros muchos ya habían llegado ¡en los años 70! Desde que tengo la sensación de que poco nuevo hay bajo el sol y de que es mucho más rápido y menos doloroso aprender de los errores ajenos que de los propios, procuro leer y formarme mejor en lo que respecta a dirección de proyectos, pero, ¿hacemos esto todos o estamos condenados a repetir los mismos errores una y otra vez?

Si tomásemos como referencia el número de directores de proyecto certificados como Project Management Professional PMP® (una de las certificaciones más populares y de la que más fácil me ha sido encontrar 5

www.proiectus.es

Número 1, Noviembre 2013

estadísticas) vemos que España se sitúa, por número de poseedores de la certificación en la posición número 16 del total de 197 países con presencia en el Project Management Institute (PMI), un dato cuánto menos interesante.

El número de socios del PMI en Canarias representa solo el 0,49% del total de socios en España pero si tenemos en cuenta que Canarias tiene aproximadamente el 4,5% de la población de todo el país. Ya sé que tenemos una industria menos fuerte pero ¿justifica esto una proporción de socios 11 veces inferior a la media nacional? ¿Nos preocupamos por la dirección de proyectos?

Si ahondamos algo más en esas cifras, vemos que España ha alcanzado esa posición a marchas forzadas en los últimos años. En el plazo de un año, el número de socios en España se ha visto incrementado en un 42,68% frente a solo el 8,76% de incremento en la media mundial. Parece que a nivel nacional los directores de proyecto se preocupan cada vez más por la gestión pero, ¿y en Canarias?

REFERENCIAS Presente y futuro del Project Management Institute (PMI) en España, Jesús Vázquez, PMP®, Vicepresidente 1º del Capítulo de Madrid del Project Management Institute.

www.proiectus.es

Número 1, Noviembre 2013

EDUARDO GUTIÉRREZ BAHILLOngeniero de Caminos, Canales y Puertos por Jefe de Obra Senior en Ferrovial Agroman. En sus casi 15 años de desarrollo

profesional ha estado involucrado en diversos proyectos de construcción, tanto para clientes públicos como para privados. Actualmente desempeña el puesto de Gerente de la UTE Adeje -Santiago del Teide, encargado del tramo sur de las obras del Anillo Insular de Tenerife con un presupuesto de 190 millones de euros.

DIRECCIÓN DE PROYECTOS EN CONSTRUCCIÓN PÚBLICA. EL PUESTO DE JEFE DE OBRA

OBRA

INTRODUCCIÓN El puesto de Jefe de Obra se encuentra entre los clásicos perfiles profesionales de gestión de proyectos. Hay que aclarar que su misión se encuentra fuertemente contextualizada y condicionada por diversos aspectos muy a tener en cuenta en el momento de enfrentarse a la misión de materializar una idea a plena satisfacción de todos los intervinientes en el proceso.

de obras. De estos últimos, también pueden darse algunas variantes, como son los contratos de proyecto y obra y los contratos de pago aplazado. Éstos últimos suponen una fuente de financiación público-privada para acometer un determinado proyecto que es financiado por la empresa privada hasta su completa finalización a satisfacción de la Administración. En el momento de la terminación de la obra, el Contratista recibe el abono de la totalidad de la obra con un tipo de interés previamente pactado.

Con el fin de centrar más la labor del Jefe de Obra y su desempeño como Project Manager, voy a referirme, exclusivamente, a los Contratos de Obra Pública cuyo cliente es la Administración.

Lo cierto es que ese tipo de contratos son menos habituales que los contratos tradicionales en los que existe un proyecto de construcción, que se adjudica a una empresa constructora, tras superar con éxito el proceso de licitación de la misma.

Como se puede intuir, debido a que se trata de un contrato con la Administración Pública, se encuentra fuertemente regulado y el marco legal juega un papel transcendental en la Gestión de un proyecto de estas características.

En este artículo voy a introducir este tipo de contratos en los que existe un proyecto de construcción que se ejecuta según un programa preestablecido y que se abona mediante pagos a final de mes.

Entre los contratos con la administración, se pueden distinguir, grosso modo, contratos de servicios, contratos de suministro y contratos 7

www.proiectus.es

Número 1, Noviembre 2013

PROYECTO DE CONSTRUCCIÓN

la obra, así como los criterios de calidad, ensayos a efectuar, criterios de aceptación y rechazo, tolerancias, normativa a aplicar de obligado cumplimiento y, finalmente, los criterios de medición y abono.

En el caso que nos ocupa, el alcance del contrato viene definido a través de un documento oficial que hasta hace un tiempo requería el visado de un colegio de Ingenieros profesional oficial, y que se denomina “Proyecto de Construcción”. El proyecto de construcción puede haber sido redactado directamente por la administración a través de sus departamentos técnicos, o, lo que se produce con mayor frecuencia, es que haya sido encargado a una empresa especializada en la redacción de proyectos de construcción. Como veis, este tipo de encargo, a su vez, lleva su propia gestión, pero este asunto no es motivo del presente artículo. El proyecto de Construcción, consta de los siguientes documentos: 1. Memoria y anejos de Cálculo.

En el Presupuesto quedan reflejadas las mediciones estimadas para la realización de los trabajos, así como los precios (unitarios) de todas y cada una de las unidades de obra que componen la solución final. A su vez, los precios unitarios se descomponen en precios elementales de mano de obra, materiales y maquinaria. Dentro del presupuesto existe un documento denominado “Cuadro de Precios 1” donde se establecen en letra y número el precio unitario de todas y cada una de las unidades del proyecto.

2. Pliego de Prescripciones Técnicas Particulares. (PPTP) 3. Presupuesto.  Mediciones.  Precios unitarios.  Presupuesto total 4. Planos. En la Memoria y anejos de cálculo, se relatan las necesidades por las que se justifica el proyecto y se describen de forma literal las distintas actuaciones y soluciones técnicas que conforman el diseño de la obra a ejecutar.

Multiplicando las mediciones de todas las unidades por sus precios unitarios, se obtiene el denominado Presupuesto de Ejecución Material (PEM). El valor del PEM es aumentado en un porcentaje de Gastos Generales (habitualmente entre el 15 y el 20 %) y un

En el PPTP se establecen las definiciones técnicas de las distintas unidades que definen 8

www.proiectus.es

Número 1, Noviembre 2013

porcentaje por Beneficio Industrial (habitualmente entre el 3 y el 8%)

técnica y la propuesta económica. En la propuesta técnica se analizan aspectos como mejora del plazo inicial, medios humanos para su ejecución, maquinaria disponible, procesos constructivos, etc… En lo referente al aspecto económico se suelen establecer fórmulas que asignan puntos en función de la oferta. Existen múltiples fórmulas, algunas dan más puntos al más barato, otras otorgan más puntos a aquellas ofertas que se aproximen más a la media aritmética de los ofertantes, etc.

Tras aplicar los porcentajes de Gastos Generales y Beneficio Industrial se obtiene el Presupuesto de Ejecución por Contrata (PEC). En los Planos se recogen las representaciones gráficas de las distintas partes del proyecto para una correcta comprensión e interpretación del mismo. PROCESO DE LICITACIÓN Y ADJUDICACIÓN

La propuesta ganadora según el Órgano de Contratación, procede a firmar el contrato con la administración.

Una vez que la Administración tiene el proyecto de construcción, bien por haberlo redactado ellos mismos o bien por haber encargado su redacción, se procede a la adjudicación del Contrato de Obra.

Contrato con la Administración Como he indicado anteriormente, hay una normativa1 muy estricta respecto a los contratos firmados con la administración, pero conviene saber que los documentos contractuales son los siguientes:

Este procedimiento se encuentra fuertemente regulado por Ley, para atender al cumplimento de los principios de publicidad, mérito y capacidad de las empresas que pretenden firmar este tipo de contratos con la administración. Para no ser muy árido en la explicación, y con el fin de que el artículo resulte lo más instructivo posible, en el concurso de Adjudicación, se establecen las bases a través de las que se valorarán las distintas propuestas realizadas por las empresas. Hay varios mecanismos para adjudicar las obras. Un modelo que apenas se usa para obras de importancia es la subasta. Se adjudica la obra a la empresa que, cumpliendo todos los requisitos técnicos, administrativos, etc… realiza la oferta más barata. El modelo mayoritariamente utilizado es el de concurso. En este proceso, la administración divide la puntuación en dos aspectos: la propuesta

Real Decreto Legislativo 3/2011 de 14 de noviembre por el que se aprueba el texto refundido de la Ley de Contratos con el sector público.

www.proiectus.es



Pliego de Bases Administrativas para la Adjudicación.



Oferta del Contratista.



PPTP del Proyecto.



Planos del Proyecto.



Cuadro de precios 1 del Proyecto.

Número 1, Noviembre 2013

sentido que no se trata de hacer un contrato a precio cerrado. Se confía en que las mediciones estén bien consideradas y que para llevar a cabo lo que se indica en los planos sean correctas, pero se admite por ley que haya una diferencia de hasta un ±10% en las mediciones de proyecto. Este exceso presupuestario en unidades contratadas se llama tradicionalmente “liquidación”.

Como podéis ver, no todos los documentos del proyecto de construcción son contractuales. Así, por ejemplo, el presupuesto no lo es. Solo son contractuales los precios unitarios.

He querido dedicar suficiente tiempo a todas las labores previas a la Dirección del proyecto en el momento en el que se encarga al Jefe de Obra la correcta ejecución de los trabajos. Con todos estos antecedentes, el Jefe de Obra hereda un contrato que hay que cumplir y que le viene dado. Tiene que ejecutar una obra con unos precios unitarios determinados, en un plazo acordado y con una calidad requerida, de forma que para la empresa contratista resulte beneficioso desde el punto de vista empresarial.

Eso sí, los precios unitarios son contractuales después de aplicar el llamado Coeficiente de adjudicación a todos y cada uno de los precios. Poniendo un ejemplo, si se trata de un proyecto de ejecución de una carretera, con un presupuesto total de 10 millones de euros y el contratista ganador en la adjudicación ha propuesto un presupuesto total de 9 millones de euros, el Coeficiente de adjudicación será 0,9 y todos y cada uno de los precios unitarios del proyecto se verán afectados por este coeficiente. Así, por ejemplo, m3 de excavación en todo tipo de terreno con medios mecánicos, incluso arranque, carga y transporte a lugar de empleo o vertedero 5,00€ (cinco euros), en el documento contractual aparecerá afectado por el coeficiente de 0,9 por lo que el contratista cobrará por cada metro cúbico que excave 5,00x0,9=4,50€. Esto es lo que popularmente se conoce como “baja” del proyecto.

A partir de este momento, entre las tareas del Jefe de Obra están: Gestión del Coste El Jefe de Obra deberá hacer una previsión hasta el final del contrato para informar a su empresa sobre las expectativas económicas de la obra, así como su planificación. Se exige que, mes tras mes, se anticipe al volumen de producción que va a ser capaz de desarrollar, así como al resultado mensual de la cuenta de explotación. Entre los costes a considerar, la clásica clasificación del coste es:

Supongo que os habrá llamado la atención que el presupuesto no sea contractual, en el 10

www.proiectus.es



Número 1, Noviembre 2013

Coste Directo. Es aquel coste estrictamente imputable a las distintas unidades de obra



Costes Anticipados. Son aquellos en los que se incurre antes de empezar la producción: licencias, vallados, etc…



Costes inmovilizado. Aquellos que hay que amortizar a lo largo de la obra y que intervienen en todas las unidades del proyecto. Mobiliario, instalación de grúas, instalaciones auxiliares de obra…



Costes Corrientes. Los sobrevenidos por el paso del tiempo, se haga producción o no. Personal asignado a la obra, alquileres, “facilities”, etc..



Costes Externos. Las obras de la administración a veces llevan un pago que se llama “tasa de inspección” para cubrir los costes de la administración, además está la tasa de ensayos y los costes estructurales de la empresa, fuera de la obra: delegación, central etc…



Costes Diferidos. Es una provisión de gasto, para una vez terminada y entregada la obra hacer frente a gastos de retirada de instalaciones, pequeñas reparaciones en período de garantía, etc…

Gestión de la Calidad La ejecución del contrato debe enmarcarse dentro de los estándares comúnmente aceptados para la ejecución de obras. Existen muchas normativas técnicas de obligado cumplimiento y otras referencias técnicas a modo de recomendación. Lo que sí hay que cumplir es con los requisitos mínimos dispuestos en el PPTP, a través de un adecuado control y registro de los ensayos mediante el Plan de Aseguramiento de la Calidad. Se registra la trazabilidad de los materiales, ensayos, no conformidades, acciones correctoras, etc… Gestión de la Prevención Este es un tema con implicaciones de responsabilidad civil y penal. Es un tema amplio, pero quiero avanzar alguna cosa. En la fase de proyecto, el proyectista redacta un Estudio de Seguridad y Salud donde se analizan los riegos de las actividades a desarrollar así como las acciones preventivas que los reduzcan. Una vez adjudicada la obra, el Jefe de Obra debe de desarrollar ese Estudio de seguridad y adaptarlo a los procesos constructivos propuestos. El documento que recoge esto es el Plan de Seguridad y debe ser aceptado por el Coordinador de Seguridad antes de iniciarse los trabajos. Cualquier modificación o incumplimiento de Plan de Seguridad puede conllevar responsabilidades penales por poner en riesgo la salud de los trabajadores.

Gestión del Tiempo El tiempo juega un doble papel. Por un lado el plazo de finalización contractual, que puede irse incrementando mediante prórrogas y por otro el plazo de ejecución para el control del coste corriente, ya que una desviación en el tiempo supone una desviación en el coste.

Gestión de Compras Por supuesto, dentro de la gestión de costes y su control, el primer momento dónde se tiene que trabajar duro es en hacer una buena contratación, tanto de mano de obra 11

www.proiectus.es

Número 1, Noviembre 2013

como de suministro de materiales y maquinaria. El coste que se ceda en hacer una mala contratación no se recuperará jamás. Por el contrario, todo lo que se haya ahorrado en hacer una buena contratación, bien planificada y con un alcance perfectamente conocido por los ofertantes, será dinero ahorrado para la determinación del Coste final total del proyecto. Gestión Medioambiental Todos los proyectos deben someterse, según su importancia a distintos instrumentos de control medioambiental. De esto se encarga la administración. Normalmente, los proyectos de cierta consideración hay que someterlos a la obtención de una Declaración de Impacto Ambiental (DIA) positiva. Si no se obtiene una DIA positiva, no se puede llevar a cabo el proyecto. En la mayoría de los casos, se obtiene una DIA positiva condicionada. Es decir que dan luz verde al proyecto pero cumpliendo una serie de requisitos. Cualquier modificación o alteración sustancial de las condiciones medioambientales del proyecto aprobado mediante DIA positiva debe de obtener una nueva aprobación. Este tipo de trámites suelen alargar mucho los plazos de las obras.

suponga ejecutar la obra muy por debajo del coste estimado inicialmente. Esta es una de las razones, relativamente incomprensibles, por las que ninguna empresa extranjera ejecuta obras en España, pese a que muchas veces la importancia de las licitaciones obligan a su publicación en el Boletín Oficial de las Comunidades Europeas y son licitaciones internacionales. Pero este asunto abrirá otro futuro debate en la recién creada revista

CONCLUSIONES Como habéis podido apreciar en esta breve semblanza de las labores del Jefe de Obra como Project Manager, son muchas las responsabilidades que tiene que soportar para llevar a cabo un proyecto a plena satisfacción de todas las partes. A toda estas innumerables labores de coordinación hay que sumar que, en la mayoría de los casos el punto de partida para obtener el contrato ha supuesto que el coeficiente de adjudicación 12

PROIECTUS.

www.proiectus.es

Número 1, Noviembre 2013

AGUSTÍN TAPIA QUESADA

Responsable de las Áreas de Desarrollo, Administración Electrónica, Turismo y Sanidad de Open Canarias.

¿BLANCO O NEGRO? ¿METODOLOGÍAS ÁGILES? ¿SCRUM O PMBOK? Pero este debate, ¿se plantea en serio? Como parece que sí, y digo que sí, porque una de las pregunta de rigor entre cualquier encuentro de profesionales del sector es ¿aplicas SCRUM o PMBOK? Pues por eso me lanzo a escribir este artículo, para al menos, desahogarme. Desahogarme en voz alta sobre porqué considero tan útil y productivo el debate, como debatir qué equipo es mejor, si el Barcelona o el Madrid, o si el Brasil de Pelé o la España de Iniesta... porque, aunque puede que sea muy divertido y ameno, y puede que le echemos muchas buenas horas de discusión apasionada, al terminar de hablar, ni el madridista será culé, ni Pelé será fan de España, ni ejecutaré todos los proyectos con Scrum... ni tampoco con PMBOK.

PESADAS

pesados o formales decía que si respondes a estas cuestiones en su mayoría NO, pues ágil, y si se responde SÍ, pues pesado o formal:         

Aunque a mí, la analogía que más me gusta es que comparar Scrum con PMBOK es como comparar qué coche es más rápido el de Alonso o el de Loeb... no voy a decir (aunque lo esté diciendo) lo obvio que es que no hay una respuesta absoluta, que todo es relativo.



¿Se requiere una especificación? ¿Los clientes son inaccesibles? ¿El sistema a construir es muy grande? ¿El sistema es muy complejo? ¿Se trata de un producto con mucho tiempo de vida previsto? ¿Tienes herramientas de desarrollo limitadas? ¿El equipo está distribuido? ¿El equipo viene de una cultura de la documentación? ¿El equipo tiene conocimientos técnicos limitados? ¿El sistema a construir está sometido a regulación legal?

Sin entrar a valorar lo correcto de las preguntas o respuestas, sí estoy completamente de acuerdo en que cada proyecto, cada cliente, cada equipo de

El cuestionario del libro “Software Engineering” de Sommerville, para valorar cuándo ser ágil o cuando usar métodos 13

www.proiectus.es

Número 1, Noviembre 2013

trabajo, cada situación requiere un modo concreto de gestión.

proyecto). Bueno, a la documentación y a la “explicitación” de lo que se documenta.

Un colega de profesión me dijo en una ocasión que ellos ya no utilizaban diagramas de Gantt que no planificaban. Cuando pregunté, por pura curiosidad, ¿porque?, me afirmó con rotundidad que porque la metodología que ellos seguían decía que no había que planificar. “Nosotros es que aplicamos la Metodología Scrum, y esta metodología dice que nunca puedes saber lo que vas a hacer más adelante y que no se planifica”. Lo curioso es que su cliente le había pedido un calendario de hitos, me hubiera gustado ver la cara del cliente si el argumento por no entregarle el calendario iba a ser ese.

¿Es necesario hacer una Acta de una reunión con el cliente? ¿es necesario reflejar los Revista PROIECTUS, Número 1, Septiembre 2013 acuerdos a los que hemos llegado? “Hombre Agustín, yo soy Ingeniero de Software, tendría que estar produciendo, programando!!, tendría que estar generando “valor” al cliente, ya eso lo hablé con él y quedó claro ¿para qué el Acta?, te lo digo por productividad...” No sólo exijo que se documente en un Acta, sino que si es posible, en la propia reunión al acabar se lean los acuerdos a los que acabamos de llegar, que se insista en que va a mandar un Acta y va a reflejar en ella los acuerdos. Que si se puede, que se aclare si son los acuerdos a los que se ha llegado en la reunión.

También, por aquel entonces, en una reunión de lanzamiento de un proyecto con un cliente, donde le explicábamos el enfoque del proyecto, la metodología, el alcance, calendario, etc. al llegar al apartado de “Seguimiento y Control” le expusimos que para cada Iteración llevaríamos el seguimiento con Burndown y que las estimaciones las afinaríamos iteración tras iteración con Planning Póker. Sincero fue el hombre, que esos inventos de friquis no le daban ninguna garantía en proyecto serio como éste.

Podría escribir cientos de casos en los que un acuerdo verbal entre un desarrollador y un cliente llega un punto, pasadas unas semanas y con el acuerdo ya ejecutado, en que parece que en lugar de un acuerdo hay dos, lo que acordó el desarrollador y lo que acordó el cliente. ¿Cuánto cuesta resolver en desencuentro? ¿es productivo? ¿Para qué el Acta? ¿para qué la conformidad del Acta? No es para tener prueba documental (bueno, quizás, pero sólo un poco), sobre todo es para que todos los involucrados en la reunión tengan la misma visión del acuerdo. Y ¿esta es una tarea productiva? No, es una tarea preventiva. Si hay una discrepancia oculta, hay que explicitarla cuanto antes, hay que prevenir, hay que forzar a que nos demos cuenta de que no habíamos llegado realmente a un

Mucha de la gente que me conoce ha llegado a la conclusión que estoy completamente en contra de los principios del desarrollo o la gestión ágil. ¿Porque han llegado a esa conclusión? Porque le doy mucha importancia, tanta que lo exijo constantemente, a la documentación (de los aspectos que considero esenciales del

www.proiectus.es

Número 1, Noviembre 2013

acuerdo cuanto antes, no cuando el daño esté hecho.

escorpión que picó a la rana, a veces sólo escucha lo que quiere escuchar, y nuestra labor es que lo escuche todo.

Lo del Acta es un ejemplo, cualquier otro ámbito del proyecto, ¿es necesario un documento de Análisis? Con el software que funciona es suficiente!, es el mejor documento de análisis!! ¿y si cuando enseñas el software que funciona no es lo que el cliente espera? ¿y si ahora no te quiere aprobar la factura?

Por otro lado, si tu equipo de trabajo conoce los objetivos del proyecto, conoce la necesidad del cliente, sabe cuándo una decisión técnica tiene implicaciones que hay que considerar, que para cumplir ese hito que va con retraso le echa horas, que asume una decisión técnica que no siendo la ideal es la que encaja en el proyecto por tiempo y esfuerzo. Si tu equipo se autocompensa cuando alguno se retrasa o tiene problemas. Si tu equipo te informa de que hay un retraso identificado con tiempo suficiente, si tu equipo cada vez que entrega algo lo hace sin errores y según lo acordado... Si tu equipo controla la tecnología y lo que no sabe lo aprende y hasta lo difunde... Si tu equipo hace autocrítica y propone acciones concretas de mejora, no se queja, solo mejora. Si todos son como hermanos, sin roces, sin discusiones estériles... Si programan cómo máquinas...

¿Cuándo creo que hay que aplicar metodologías ágiles? Básicamente, cuando buena parte de las tareas “preventivas” no sea necesario tomarlas, cuando podamos centrarnos casi en exclusiva a tareas productivas, pero ¿y esas condiciones cuando se dan? Se dan cuanto tienes un cliente, un equipo y un proyecto que te lo permite. Si tu cliente está disponible y tiene tiempo para el proyecto, si es un interlocutor autorizado (puede tomar y toma decisiones) y hay confianza absoluta “bidireccional”, confiamos en él y él confía en nosotros, no hace falta hacer Actas, ¿para qué gastar el tiempo? Si tu cliente “sabe” cómo va el proyecto, ¿para qué hacerle un informe de seguimiento? Ese cliente nunca se negaría a pagarte la factura, habíamos acordado el software con ese funcionamiento, no hacía falta el documento de Análisis.

Leñe, si tienes ese equipo, te sobra decirles lo que tienen que hacer, te sobra hacerles seguimiento... vaya!, quien sobra eres tú!!! ¿has tenido el placer de tener este equipo? ¿nunca has tenido un equipo que se queja y discute pero no avanza? ¿nunca tu equipo ha tenido disputas por cuestiones técnicas en posturas irreconciliables? ¿nunca se ha ofendido un técnico porque has cambiado la asignación de un trabajo porque no parecía terminar? ¿nunca un miembro de un equipo se ha ido a casa antes mientras otro se ha quedado hasta la noche? ¿nunca un técnico ha tomado una decisión técnica sin consensuar que ha provocado un problema en el proyecto?

Pregunto ¿alguna vez has tenido un cliente así? ¿seguro que sí? Bueno Agustín es que mis clientes confían en mi equipo, ¿sí?, ¿nunca te han cuestionado una estimación? ¿nunca has asumido un “poyaque” que te ha ocasionado no llegar con el alcance previsto en la fecha prevista y luego parece que te lo hayas inventado tú? El cliente es cliente, y bueno... se lleva en los genes, como el 15

www.proiectus.es

Número 1, Noviembre 2013

Vamos, tenemos nuestros sentimientos, nuestro orgullo, somos un puntito egoístas, cuando programamos no nos soporta ni nuestra novia... somos humanos!

Entonces, ¿Cuando no habrá que invertir en todas esas acciones preventivas y sólo en productivas?, pues eso, cuando tu equipocliente-proyecto te lo permitan.

¿Y el proyecto?

He llevado las cosas al extremo y no he pretendido menospreciar a nada ni a nadie, considero que en el caso las metodologías ágiles, al menos su aplicación más purista, es muy muy complicado conseguir un escenario, escenario de cliente-equipo-proyecto, lo suficientemente maduro que nos permita aplicarlas con la literalidad o libertad que nos gustaría.

¿Has trabajado en un proyecto donde hayas entregado varias versiones de la misma funcionalidad durante 3 meses hasta que el cliente queda satisfecho? Tu cliente aportando ideas, cambios, refinando... 3 meses de trabajo, 6 personas... y una funcionalidad, ahora sí! Esta es la “Cesta de la compra” que quería!! Le pasas la factura del trimestre a tu cliente, “Funcionalidad Cesta de la Compra”, 3 meses, 6 Ingenieros de Software, total chorromill euros. ¿de verdad?!! ¿no te ha cuestionado la factura? Vale tenemos la “Cesta de la Compra” y ¿dónde está el TPV? ¿no te suena?

De todos modos, muchos de los elementos introducidos en la Gestión de proyectos por las metodologías ágiles han proporcionado un clima de trabajo muy muy productivo, el feedback continuo, el seguimiento, la implicación, el compromiso...

Yo creo que un cliente quiere resultados, y los quiere en un calendario, quiere además gastarse poco o menos aún. Está bien aceptar cambios y refinar, pero el cliente debe conocer el coste de esos cambios y el impacto en el proyecto, si seguimos sobre la “Cesta de la Compra” retrasamos el TPV. Si tu proyecto puede permitirse estas licencias y no está sujeto a un calendario o presupuesto, perfecto. Si debes cumplir un calendario y un presupuesto, el cambio es bienvenido, pero es bienvenido el “cambio completo”, un cambio no es sólo de la funcionalidad o del requisito, un cambio incluye el cambio en el calendario y el consiguiente incremento de presupuesto. Por cierto, ¿Hay que estimar el cambio y que el cliente acepte (o no) el cambio o lo hacemos sin más? ¿y las horas de la estimación? ¿van a costa del proyecto?

En definitiva, la combinación de los elementos de los dos mundos en función de tu equipo, de tu proyecto y de tu cliente te dará la pauta del modelo de gestión a aplicar. A mis colega de profesión, le dije que tenía que planificar, que como le fuera con ese discurso lo iban a echar a patadas, y sobre mi cliente, me ofrecí a formarle en Scrum, que los resultados son muy sorprendentes y que seguro que le iba a resultar mucho más ameno y productivo llevar el seguimiento ahora que antes. ¿Barcelona o Madrid? Chaval! que yo juego a la liga Marca, cojo de aquí y de allí a los jugadores que quiero, mi StarTeam seguro que ganaba a los dos equipos, a la Brasil de Pelé y a la España de Iniesta... ¿qué no? ¿discutimos? 16

www.proiectus.es

Número 1, Noviembre 2013

MANUEL VARA GONZÁLEZ Responsable de proyectos en Nartex Software, con más de 15 de experiencia profesional. Licenciado en Administración de Empresas por la Universidad Autónoma de Madrid, Master en Dirección Financiera y Control por la Escuela de Organización Industrial, y Project Manager certificado por la Universidad de Stanford (USA).

CÓMO HACER ORGANIZACIÓN

REALIDAD

El éxito y la supervivencia a largo plazo de tu organización pasa por saber alinear lo que se hace con lo que desea hacer. Para lograrlo es imprescindible una buena implementación y eso sólo se puede lograr a través de una excelente gestión integral de proyectos.

LOS

SUEÑOS

utilización de los recursos disponibles para la realización de nuestras prioridades estratégicas. Vamos a explicar esto con más detalle. Una organización trabaja principalmente en:

Pero, ¿qué es la Gestión Integral de Proyectos? Empecemos por decir que es más que un conjunto de jefes de equipo trabajando con un equipo de técnicos expertos en un esfuerzo común para completar un determinado “output”. Tampoco se trata, por supuesto, de aisladas iniciativas heroicas que den buen resultado en forma de un buen producto o servicio de vez en cuando.

Definir (Estrategias)

Implementar (Proyectos)

Operar (Resultados)

La Gestión Integral de Proyectos es mucho más que crear y actualizar los diagramas de Gantt de todos los proyectos que tengamos en marcha e informar de su estado a la dirección.

Estas tres áreas de trabajo y su coordinación son fundamentales para el éxito de una organización. Sin embargo, el enfoque histórico en la gestión y el estudio de cada una de estas áreas ha sido mutuamente excluyente.

Es, sin embargo, un proceso estructural que permite convertir las estrategias de una organización en resultados operativos concretos. Una adecuada Gestión Integral de Proyectos es la que asegura la óptima

Concretamente, las operaciones, definidas como un conjunto de habilidades y técnicas compatibles con procesos de producción definidos, ha sido el aspecto principal del estudio de la gestión empresarial desde sus 17

www.proiectus.es

Número 1, Noviembre 2013

inicios. Se incluyen aquí iniciativas tales como estudios de tiempo y movimiento, servicio al cliente, evaluación de desempeño profesional, ciclos de vida de desarrollo, estudios de productividad, normas, gestión financiera, organigramas, etc.

Como ejemplo podemos citar la aparición de las primeras "empresas .com " que nacieron de una estrategia sin evidencia histórica de viabilidad. Los inversores vieron estas empresas emergentes como un área más donde poner su dinero, con la esperanza de que al menos alguna de ellas acabara siendo un éxito financiero. Este es claramente un entorno en el que el enfoque estratégico predomino y sigue siendo una estrategia muy empleada por los fondos de inversión en “startups”.

Dado que la capacidad de la organización para gestionar “lo que hace indica el éxito a corto plazo, a menudo es el área que recibe atención prioritaria. Ser “el mejor en lo que hacemos” evidencia un comportamiento operativo exitoso.

Pero el ritmo vertiginoso al que se mueve el mercado en el que operan hace que las estrategias de cambio que necesitan implementar las organizaciones para mantenerse en vanguardia, o no quedarse atrás, magnifica el impacto de la falta de conexión entre las estrategias y las operaciones del día a día.

Por otro lado, saber “qué es lo mejor” evidencia un buen comportamiento estratégico. La creación de estrategias puede ser un proceso gestionado de forma explícita o el resultado de los esfuerzos aislados de miembros de la organización. El método para el desarrollo de estrategias puede ser “topdown”, impulsado por la dirección, o de “base” en el que niveles inferiores de la organización generan tendencias estratégicas con sus acciones, generalmente exitosas en el corto plazo.

La capacidad de la organización para implementar una estrategia determinada y convertirla en éxito en las operaciones del día a día se perfila como crítica y puede ser entendida como un conjunto de procesos, habilidades y técnicas que permiten a la organización "convertir los sueños en realidad" y producir resultados esperados, consistentes, fiables y predecibles. Esto sólo puede lograrse a través de la excelencia en la gestión integral de proyectos.

Las técnicas, habilidades y procesos para la creación de estrategias han sido un aspecto muy estudiado de la gestión empresarial en las últimas dos décadas. Es evidente que fruto de estos esfuerzos, las empresas son cada vez más eficaces en el desarrollo de estrategias para orientar el futuro de sus operaciones. El constante desarrollo técnico, la mejora en la habilidad y la rapidez que se exige hoy en día para llevar nuevos productos al mercado aumenta la importancia de la implementación de estrategias, asumiendo el riesgo de disminuir la importancia de la excelencia operativa (ser el mejor en lo que hacemos).

Su aplicación dentro una incluye la capacidad para: 

Traducir la tangibles.

estrategia

organización, en

términos

www.proiectus.es

Número 1, Noviembre 2013



Alinear el trabajo de la organización con las estrategias actuales.



Alinear los recursos adecuados con las prioridades.



Alinear el trabajo de la organización con el cambio emergente.



Alinear la interdependencia diversos esfuerzos de trabajo.



Alinear los indicadores de desempeño con las prioridades de la organización.



Alinear la cartera de proyectos de la organización con sus estrategias prioritarias

individual de cada uno de los proyectos, mediante la aplicación del conocimiento recogido en la Guía de Fundamentos para la Dirección de Proyectos (Guía del PMBOK®) del Project Management Institute (PMI) y la ayuda de profesionales certificados en dirección de proyectos Project Management Professional (PMP)®.

los

De este modo, garantizaremos que se cumple con la estrategia de la organización mediante la implementación de operaciones sostenibles que aseguren el éxito y la supervivencia de la organización.

REFERENCIAS

La gestión coordinada entre estrategias y operaciones de forma estrecha hace que “el todo sea mayor que la suma de las partes consideradas individualmente”, cada uno de las mejoras de forma independiente en alguna de las áreas de trabajo aumenta la capacidad de la organización para tener éxito. Sin embargo, una mejora sinérgica que afecte a todas las áreas, con una alineación consciente, asegura el éxito de la organización.

Converting Strategy into Action, Ray Levitt. Mastering Solutions.

El eje central de este modelo, el puente que completa el camino desde las estrategias hacia las operaciones, es la implementación, ¿cómo? a través de la Gestión Integral de Proyectos. Para ello disponemos de sistemas de gestión de la cartera de proyectos y de la definición de programas integrados que nos permitirán manejar de forma eficiente los proyectos elegidos para implementar nuestras estrategias. No menos importante para el éxito de nuestra gestión integral es la gestión 19

the

Integrated

Program,

IPS

www.proiectus.es

Número 1, Noviembre 2013

JUAN CARLOS FALCÓN PORTILLO Jefe de Proyectos en Inerza S.A. especializado en desarrollos "llave en mano".

Interés constante en nuevos proyectos y metodologías de trabajo: SCRUM, EVM, etc.

IMPLANTANDO SCRUM EN LAS EMPRESAS La implantación de una metodología o framework de trabajo en una empresa, no es tarea fácil y SCRUM no podía serlo menos. He oído de empresas que han empezado a utilizar esta metodología y a las pocas semanas han comentado que no sirve, que no se adapta a su empresa etc.

seguir para ver, si podíamos trabajar con SCRUM. Con las ganas de cambio inculcadas en los equipos de trabajo y el gusanillo detrás de la oreja, el primer paso fue el proyecto. No para todos los proyectos pueden utilizarse metodologías agiles; alguno porque no se adaptan, otros porque el cliente no quiere ni oír la palabra ágil. El proyecto que consideramos no era complicado y aun así desde el principio ya comenzaron los problemas.

En contraposición a las metodologías tradicionales donde todo o casi todo está definido desde el principio, SCRUM pretende ir definiendo el proyecto y su desarrollo sprint a sprint (15 días en 15 días). Los proyectos cerrados, desde el primer día conocen que se va a realizar dentro de seis meses. Pensémoslo fríamente ¿no es mejor pensar en que vamos a desarrollar en 15 días que no dentro de 6 meses? La mayoría de nosotros podemos pensar qué vamos a desarrollar en quince días y llegar a cumplirlo, sin embargo según avanzamos en el tiempo empezamos a divagar.

Por parte del cliente no existía el perfil del “Product Owner”, así que no tuvimos más remedio que asumir este rol por parte de un miembro de nuestro equipo. Se mantenían reuniones periódicas con el cliente, se delimitaba que era lo más prioritario y finalmente, este miembro determina que historia era la más prioritaria. Primer punto salvado.

Nosotros, cuando nos planteamos comenzar a utilizar esta metodología o framework, como muchos lo llaman, comenzamos con un periodo de formación, estudiando material que existía por Internet y recibiendo un curso de formación. A partir de este punto nos planteamos que directrices deberíamos

El equipo de trabajo estaba muy motivado, sobre todo con el concepto de que ellos iban a estimar el tiempo que duraría una tarea, sin embargo fue difícil desgranar las historias en tareas más pequeñas. Pensar antes de programar. En este punto ayudaron mucho los post-it, al no permitir escribir mucho en 20

www.proiectus.es

Número 1, Noviembre 2013

ellos, fue necesario pensar en las tareas detenidamente; que debía realizarse primero, si estaba suficientemente desgranado para la posterior planificación etc.

donde los equipos y la organización aprendan y estén todos motivados. Y sobre todo y lo más importante, implantar las metodologías agiles adaptándolas a tus necesidades. No intentes llevas a la práctica todo desde el primer día, progresa poco a poco, día a día y no intentes tampoco llevar a la práctica algo que realmente no sirve para tu organización o no aporta ningún valor añadido a los proyectos.

El mayor obstáculo surgió a partir del tercer/cuarto sprint. La famosa deuda técnica. Primero probamos a guardarla y planificar un Sprint con todos los fallos que íbamos obteniendo en las pruebas y test unitarios. Lo que debía ser dos semanas, un sprint, se convirtió en cuatro amenazando con más semanas y no avanzar en el proyecto. En una reunión de retrospectiva, optamos entonces por planificar la deuda técnica dentro del sprint, mejorar las pruebas y test unitarios, determinar mejor que es una tarea terminada definiendo diez pasos para ello. Después de cuatro sprint la cosa mejoro bastante. Mi recomendación es que primero se cuente con los equipos de desarrollo, que en definitiva son las personas que tienen que comprometerse a tener una tarea finalizada y no me refiero a programada, que eso siempre es fácil, sino desarrollada con sus test unitarios, probada e integrada con el resto de tareas, que cumpla con los estándares de calidad que fije la empresa y sobre todo con los requerimientos de usuario. Realizar las reuniones de sprint es un paso muy importante y donde realmente se puede comprobar si el equipo de trabajo funciona y responde a las expectativas. Los equipos deben estar formados. Aunque realicemos las reuniones de sprint todos los días no quiere decir que estemos utilizando metodologías agiles. Se necesita un periodo de adaptación que considero que va de cuatro a ocho meses según la empresa, 21

www.proiectus.es

Número 1, Noviembre 2013

DAVIDE MAZZANTI Project Manager para Teléfonica y Vodafone. Business Engineer, graduado por la Universidad de Bologna, ha desarrollado su carrera profesional entre las ciudades de Las Palmas de Gran Canaria, Milán y Alemania. Experto en innovación.

THE ITALIAN WAY Los italianos somos conocidos en el mundo por muchas cosas buenas como la alta moda, los coches deportivos y la mejor pizza del mundo. Pero lamentablemente también somos populares por cosas no tan buenas. Y una de las principales actitudes negativas que nos identifican es la completa falta de organización.

repente olvidan el tráfico caótico del centro de Roma. Modelos de negocios y de producción punteros que parecen haber nacido como flores en el desierto.

Es suficiente dar un paseo por el centro de Roma en cualquier momento del día, asistir a un evento organizado por italianos o, aún peor, tener que acudir a las oficinas de Hacienda para que un sentimiento de desesperación se apodere de nosotros y empecemos a maldecir el desorden crónico que caracteriza este país. Y si esta sensación es ya bastante agobiante para un italiano, acostumbrado de alguna forma a este modo de ser, nos cuesta imaginar la frustración que tiene que vivir un pobre turista al chocar con esta triste realidad.

Intentemos buscar una solución a este dilema. Una posible respuesta es que simplemente las empresas italianas siguen, como cualquier otra empresa mundial, un claro sistema de gestión de proyectos. Al fin y al cabo, el hecho de que un país esté mal organizado no tiene por qué significar que internamente las marcas también lo estén.

¿Cómo encaja entonces el éxito de estas grandes firmas con las malas costumbres organizativas Italianas?

Otra hipótesis es que estas empresas tienen la posibilidad de contratar profesionales y consultores externos acostumbrados a ritmos diferentes y buenas fórmulas de organización.

Ante esta situación cabe preguntarse: ¿cómo es posible que en un ambiente tan mal organizado crezcan grandes iconos de la industria? ¿Cómo es posible que en estas condiciones se hayan creado y se sigan desarrollando grandes proyectos de alcance mundial? Basta nombrar empresas como Ferrari, Gucci o Prada y nuestras mentes de

Hay muchos casos prácticos que pueden avalar estas primeras dos hipótesis. Ferrero (la empresa de la Nutella y el Kinder) es el clásico ejemplo de empresa cuya planta de producción sigue un rígido esquema Kaizen, donde todo el personal encargado de su gestión ha sido formado con metodologías de 22

www.proiectus.es

Número 1, Noviembre 2013

producción ágil. Diferente es el caso de Lamborghini donde, en un momento de fuerte inestabilidad financiera, la empresa se ha recuperado dejando todas las actividades principales en manos del equipo de ingenieros de la empresa madre. Tras su adquisición por el grupo Volkswagen, la gestión de los centros de I+D, diseño y prototipos la llevan a cabo profesionales alemanes desde la planta de Sant'Agata Bolognese.

ahora bien, el misterio se pone más oscuro. Si las empresas italianas, en su gran mayoría, no siguen metodologías de proyectos ágiles ni herramientas básicas de gestión de flujos de información, ¿cómo pueden seguir obteniendo grandes resultados? Para responder a esta última y crucial pregunta hay que vivir dentro de una de estas empresas. O en muchas de ellas, para encontrar un patrón que sea más o menos común a todas.

Pero estos dos casos no son más que pequeñas gotas en el mar. La realidad es bien diferente y se acerca mucho más a lo que todos nos imaginábamos desde el principio: también las grandes empresas italianas están mal organizadas.

En Italia se trabaja principalmente a través de relaciones personales. Como dirían los ingleses, es todo networking. No hay problema infranqueable que no se pueda superar hablando con la persona correcta, posiblemente comiendo juntos o durante una pausa junto a las máquinas del café. El tema es simplemente convencer a nuestros interlocutores de que dejen a un lado cualquier otra actividad menos importante que nuestro problema y se centren en nosotros. De esta manera, la gestión de proyectos se convierte en un intercambio de favores y contrafavores que adquieren importancia en función de nuestras capacidades de negociación. El flujo preestablecido de informaciones pierde relevancia y se premia un modelo basado en la gestión de las urgencias y de la flexibilidad extrema.

Autor: Roberto Vongher

Esto suena como una locura ineficiente, y posiblemente lo sea. Pero si intentamos esquematizar estas actividades de interrelación humana y las comparamos con normales flujos de informaciones estructuradas, podemos ver cómo se acerca

Pésimas prácticas de gestión de proyectos, falta de documentación, fragmentación de la información, ineficiencias, duplicación de roles y difícil identificación de responsabilidades: una mezcla que volvería loco a cualquier auditor independiente. Y 23

www.proiectus.es

asombrosamente a Production japonés.

Número 1, Noviembre 2013

modelo

Lean

enseñar la creatividad o el arte: podemos cultivar estas habilidades en una persona ya dotada, pero no podemos pretender que un niño sin habilidad artística cree una obra maestra.

Hagamos un rápido ejercicio de transposición: el solicitante es el "cliente" de la actividad o información, el productor es el "fabricante" o "proveedor" de la misma. También existe el kanban, o tarjeta, visto como favor que se transporta de forma completamente desestructurada entre los actores. El ciclo sigue las mismas lógicas del modelo japonés, con el favor que escala la cadena informativa desde el cliente hasta el fabricante de la información. Y la forma con la que viene transportado el kanban (petición de favor) determina su urgencia. Si una llamada telefónica gana sobre cualquier correo electrónico, una visita física o una reunión obtiene la máxima prioridad.

Otro aspecto importante es entender cuándo el modelo italiano puede dar beneficios reales. Su esencia es al mismo tiempo fuerza y debilidad: es muy poco eficiente, ya que cualquier decisión sigue un flujo retorcido y causa grandes pérdidas de tiempo. Pero al mismo tiempo permite priorizar de forma casi inmediata cualquier urgencia que pueda surgir durante el ciclo de producción. El equilibrio entre eficiencia y flexibilidad está desplazado fuertemente hacia la flexibilidad. Esto también nos ayuda a entender por qué Italia es famosa en el mundo por sus grandes firmas de moda. La alta moda es el clásico sector donde no importa lo rápida que sea una línea de producción o lo fiables que sean los vestidos producidos. Importa que los modelos estén al día con las tendencias y que sepan adelantar los gustos y deseos de los consumidores. Por eso es importante que todo el flujo de gestión sea lo más reactivo posible al cambio, que exista la posibilidad de parar el proceso y dar un nuevo rumbo a

Hay que tener un poco de elasticidad mental para pensar que este sistema pueda realmente funcionar. Imaginemos que estamos en un bazar de Marrakech donde presenciamos una compraventa. Echando solo un rápido vistazo, no entendemos cómo una simple contratación pueda llevar decenas de minutos. Pero casi siempre termina con ambas partes satisfechas cerrando el acuerdo delante de una taza de té. De la misma forma, el sistema italiano de gestión olvida las reglas básicas del intercambio de información, adoptando un sistema basado más en las formas que en los contenidos. Queda por preguntarse si este sistema es realmente eficaz y si merece la pena su estudio para adaptarlo a otras realidades. En primer lugar, hay que reconocer que la posibilidad de extender este modelo de forma estructurada hacia otra realidad sería prácticamente imposible. Es como intentar 24

www.proiectus.es

Número 1, Noviembre 2013

toda una colección diez minutos antes de su presentación. La otra cara de la moneda son los sectores con alta especialización y bajo riesgo sistémico. ¿Podría emplearse el modelo italiano en una fábrica de tornillos? Evidentemente no. Una excepción es la industria de coches deportivos, donde su bajo número de modelos producidos y la alta personalización de cada ejemplar premia un modelo de gestión poco estructurado. Lástima que no haya un programa Erasmus para Project Managers, porque si existiera recomendaría a todos que se tomaran un par de meses de intercambio para venir a Italia a saborear de primera mano el modelo italiano. Al principio resultaría de lo más chocante, pero creo que alguna buena lección sobre cómo hacer y pedir favores seguro podrían aprenderla. Y por qué no, ¡también comer una buena pizza!

www.proiectus.es

Número 1, Noviembre 2013

RAÚL HERRANZ Profesional independiente que trabaja como Formador y Agile Coach, ayudando a diferentes equipos en organizaciones de todo el territorio nacional a introducirse y mejoras sus implantaciones de metodologías y prácticas ágiles.

Con

conocimiento

amplia con

experiencia

las

profesional,

certificaciones

Scrum

Raúl

complementa

Manager,

Certified

este Scrum

Professional y PMI Agile Certified Practitioner.

¿GESTIONAS PROYECTOS TIC Y AÚN NO ERES ÁGIL? ¡MALGASTAS TU TIEMPO! Se dice que la agilidad comenzó con un artículo de Nonaka y Takeuchi titulado “The New New Product Development Game” (Takeuchi & Nonaka, 1986). Sin embargo, estos dos japoneses no la inventaron: este artículo era el resultado de un estudio de las condiciones que hacían que determinadas empresas estuvieran logrando grandes éxitos en sus proyectos frente a sus más directos competidores.

¿Y cuáles eran los factores que facilitaban estos logros? Frente a equipos especializados trabajando por fases, estos proyectos eran desarrollados por equipos multidisciplinares realizando las actividades requeridas sin fases, bajo demanda de las necesidades del proyecto. Y frente a la definición en una primera fase de todos los requisitos para poder realizar y seguir un plan igualmente desarrollado al inicio del proyecto, estos equipos trabajaban a partir de una visión de alto nivel del producto requerido, adaptándose a los cambios con facilidad. La idea que subyace es la de eliminar todas aquellas actividades que no aportan valor al proyecto/producto, optimizando el uso de los recursos escasos: el capital, las personas y el espacio (lo que en el modelo de gestión Lean (Lean Enterprise Institute, Inc., 2009) se conoce como “Minimización del despilfarro”). Esto, llevado a la gestión de los proyectos TIC, pasa por definir y perseguir el que debe ser nuestro objetivo principal. Por mi experiencia, logramos diferenciarnos de nuestra competencia cuando nuestro objetivo

Fuente: Wikimedia Commons Autor: Almari Malave

www.proiectus.es

Número 1, Noviembre 2013

es conseguir entregar el máximo valor a nuestros clientes con los recursos disponibles (normalmente escasos).

roles (dueño del producto, equipo de desarrollo y scrum master o facilitador), tres artefactos (pila de producto, pila de la iteración e incremento) y tres tipos de reuniones orientadas al desarrollo del producto (reunión de la planificación, reunión de seguimiento diaria y reunión de revisión), además de otra de mejora del proceso (retrospectiva).

Y aquí es donde entra lo que llamamos agilidad, un término definido en el año 2001 por diecisiete personalidades críticas con las metodologías tradicionales que se reunieron en EEUU para establecer el llamado Manifiesto Ágil. Un manifiesto en el que sacaron factor común a diferentes nuevos métodos de desarrollo, dando como resultado lo que hoy en día conocemos como los valores de la agilidad: 

Individuos e interacciones sobre procesos y herramientas.



Software funcionando documentación extensiva.

sobre



Colaboración con el negociación contractual.

sobre



Respuesta ante el cambio sobre seguir un plan.

cliente

Fuente: Mountain Goat Software

Además, existen otras técnicas ampliamente utilizadas en el mundo ágil, como por ejemplo: 

Métodos ágiles para el desarrollo de nuestros proyectos hay muchos, quizá los más conocidos sean XP (eXtreme Programming) y Scrum, pero no hay que olvidar otros como AUP (una simplificación de RUP) o DSDM (Métodos de Desarrollo de Sistemas Dinámicos). De XP hemos aprendido la importancia de algunas prácticas como la programación por parejas, la propiedad colectiva del Código, el desarrollo dirigido por test (TDD), la integración continua o la refactorización, mientras que Scrum ha aportado un relativamente sencillo proceso para gestionar nuestros proyectos, donde se distinguen tres 27

Historias de Usuario como herramienta de análisis, frente a los extensos documentos de especificación de requisitos siguiendo el estándar de IEEE 830 (IEEE-SA, 1998) ampliamente utilizados en metodologías clásicas.

www.proiectus.es



Número 1, Noviembre 2013

Herramientas visuales como los tableros Kanban para la gestión de los flujos de trabajo.

En conclusión, la Agilidad es un paradigma para la gestión y el desarrollo de proyectos que crece en importancia tal y como refleja su uso creciente por gestores y equipos de desarrollo de proyectos, especialmente en proyectos TIC aunque no limitado a esta industria (PMI, 2012). Una importancia creciente respaldada por los valores en los que se basa, y la simplificación y eliminación de todo aquello que es superfluo para la consecución de nuestro principal objetivo. Por ello me atrevo a aventurar que si aún no conoces ni aplicas las metodologías ágiles, especialmente en proyectos TIC, posiblemente estarás perdiendo un tiempo valioso para ti y para tus clientes. REFERENCIAS Must-Have Skill: Agile, (2012, 28 Febrero). Project Management Institute (PMI). What is Lean? Institute, Inc.

(2009).

Lean

Enterprise

The new new product development game (1986). Takeuchi, H., & Nonaka, I.

www.proiectus.es

Número 1, Noviembre 2013

VICENTE GONZÁLEZ MEDINA Ingeniero Técnico de Telecomunicaciones por la Universidad de Las Palmas de Gran Canaria y certificado como Project Manager Professional (PMP)® por el Project Management Institute. Trabajo desde hace 18 años en la empresa DF Núcleo, habiendo ejercido como ingeniero de puesta a punto, ingeniero de proyecto, responsable técnico de Canarias y actualmente como Jefe de Proyecto.

LA FORMACIÓN: TAREA CONTINUA ¿Estás realizando actualmente algún curso o lo has hecho recientemente? ¿Lees periódicamente información para complementar o actualizar tus conocimientos? Si a las dos preguntas respondes que no, podrías estar perdiendo el tren para un futuro mejor.

caso hay unos motivos que fundamentan esta afirmación: Trabajador en activo Lejos quedan ya los días en que la empresa era la única responsable de la formación de sus trabajadores. Aunque aún quedan empresas que siguen realizando esta práctica, las circunstancias actuales han provocado que éste no sea un hecho habitual. Por tanto, para mantenerte actualizado debes ser tú quien tome las riendas de tu educación.

Hasta hace unos años, bastaba con estudiar una carrera, conseguir un trabajo (lo que tampoco era tarea fácil) y acumular años hasta llegar a la jubilación. Hoy en día esto no es suficiente. La tarea de estar en un continuo aprendizaje se ha convertido en una necesidad para cada uno de nosotros, motivada entre otras razones por las siguientes: 

Avances cada vez más rápidos en todos los campos del conocimiento.



Aumento de la competencia para la búsqueda de empleo, con currículums cada vez más completos.

Lamentablemente, hay mucha gente que no ha asumido este cambio. Es muy común hablar con personas que se niegan a dedicar su tiempo libre a aprender nuevos conocimientos o actualizar los que ya tienen, ya que consideran que esto debería ser realizado durante su horario laboral. Trabajador en paro En situación de desempleo resulta obvio pensar que tienes que tener un buen currículum para poder aspirar a un puesto de

Independientemente de si ya tienes empleo o estás en búsqueda de uno, el principal responsable de tu formación eres tú. En cada 29

www.proiectus.es

Número 1, Noviembre 2013

trabajo. Este currículum se debe basar en la experiencia que puedas acumular y en los estudios que tengas, por lo que cuanto más completos sean, mejor será tu posición.

una entrevista de trabajo, no poder optar a trabajos que exijan idiomas. 

Fortalezas: descubre tus puntos fuertes, qué es lo que más te gusta hacer o en qué eres especialmente habilidoso, alguna característica que te diferencie de los demás. Podrían ser detalles de tu carácter (dialogante, conciliador, capacidad de concentración, control del estrés) o conocimientos adquiridos con la experiencia. En este punto hay que insistir mucho, ya que todos tenemos una combinación de habilidades y conocimientos que nos hacen únicos.



Oportunidades: qué puedes conseguir con tus habilidades actuales o futuras. Podría ser una mejora en tu puesto de trabajo, conseguir tu primer empleo o simplemente convertirte en un mejor profesional.

La empresa que busca cubrir un puesto de trabajo valora entre muchos otros los siguientes aspectos de los currículum de los candidatos: 

Experiencia disponga.

conocimientos

que



Interés demostrado por el mismo en formarse, prestando especial atención a los últimos cursos realizados o las habilidades adquiridas. De este modo se puede deducir el dinamismo de la persona y su capacidad para asumir nuevas funciones.

En cualquier caso, cada persona se tiene que preparar un plan de formación. Para ello recomiendo seguir una serie de pasos:

2. Definición de objetivos. Una vez realizado el autoanálisis, podrás tener una visión general de tu situación actual. Debes fijarte unos objetivos que disminuyan las posibles amenazas y potencien las oportunidades. Al fijarte un rumbo te podrás centrar en qué aspectos debes mejorar, qué habilidades debes desarrollar y qué conocimientos debes adquirir.

1. Autoanálisis. Se puede realizar de diversas maneras, pero una herramienta muy eficaz es mediante el análisis DAFO (Debilidades Amenazas - Fortalezas - Oportunidades). 



Debilidades: analiza tus puntos débiles. Descubre dónde tienes falta de conocimientos o de habilidades que podrían ser importantes para tu carrera. Podrían ser idiomas, habilidades comunicativas, titulación oficial, etc.

Evidentemente, el espectro de posibilidades es muy amplio. Los puntos de mejora son infinitos y serías incapaz de abarcarlos todos, por lo que debes ser muy selectivo y establecer unos objetivos realistas y asequibles. Si eres ingeniero no pretendas convertirte en médico en un par de años, sino potenciar aquellos campos dentro de tu carrera que te atraigan más y en los que veas más posibilidades futuras. Los objetivos

Amenazas: acciones negativas que te podrían afectar por esa falta de conocimientos. Por ejemplo: perder el puesto de trabajo por no poder asumir una nueva tarea, no ser capaz de superar

www.proiectus.es

Número 1, Noviembre 2013

que fijes te servirán para encauzar tu carrera profesional por donde más te interesa, explotando tus fortalezas y disminuyendo tus debilidades.

un coste elevado y ser generalmente presenciales, o decidirte por realizar alguno de los numerosos cursos gratuitos que se ofrecen actualmente desde varias plataformas online.

Yo recomiendo que te fijes unos objetivos a corto plazo (anuales) y unos objetivos finales. Se tratará de unas líneas maestras que tendrás que seguir, pero siendo conscientes de que estas deben ser dinámicas. En la vida pocas cosas permanecen invariables, ya sea porque realmente cambian o porque varía tu percepción de las amenazas y oportunidades y debes adaptarte a las mismas.

En el plan de formación debes fijar unas acciones concretas para poder alcanzar tus objetivos. Para ello la mejor opción es estudiar primeramente la oferta disponible, tanto en centros de formación físicos como en Internet, para decidir los cursos que más te interese realizar. Debes poner especial atención en que estos no coincidan en el mismo periodo de tiempo, para evitar la saturación, y en que sean compatibles con tus propias restricciones de tiempo y coste.

3. Plan de Formación. Con tus objetivos ya definidos, debes realizar un plan de formación “a medida”. No debes intentar cumplir todos los objetivos a la vez, porque podrías caer en la frustración de ver que no puedes con todo. Tienes que fijarte un plan teniendo en cuenta tus restricciones: 



Si no encuentras un curso que satisfaga tus necesidades, debes dejar el objetivo como pendiente y seguir periódicamente escaneando la oferta hasta conseguirlo. Plataformas de educación online

Tiempo: algunos podrán sacar 4 horas diarias para esta labor, otros 2 y otros piensan que ninguna. Mi experiencia me dice que siempre hay un tiempo disponible para emplearlo en tu educación, pero hay que saber buscarlo y estar en disposición de emplearlo. Puede ser a última hora de la noche (cuando el cuerpo te pide apoltronarte en el sofá), a primera hora de la mañana o exclusivamente los fines de semana.

Existen numerosos portales en Internet donde puedes encontrar las enseñanzas que necesitas. Muchas de ellas están en inglés, por lo que si éste no está entre tus conocimientos, deberías ponerlo en primer lugar en tu plan de formación. Te recomiendo algunas: 

Coste: hay que fijar un presupuesto de formación. Debes ser consciente de cuánto dinero puedes emplear sin dañar excesivamente tu economía doméstica. Puedes optar por realizar cursos en escuelas de negocios de renombre o universidades, los cuales suelen suponer 31

Coursera. Bajo mi punto de vista, esta es la mejor. Los cursos son impartidos habitualmente en inglés por profesores universitarios mediante videos semanales, con opción de añadirle subtítulos o leer la transcripción del mismo. Algunos cursos te otorgan un certificado final si pasas las pruebas. www.coursera.org

www.proiectus.es



Número 1, Noviembre 2013

Edx. Al igual que Coursera, se trata de cursos impartidos en inglés por universidades de prestigio. www.edx.org



Unedcoma. Entorno de formación abierta de la UNED (Universidad Nacional de Educación a Distancia) dónde podrás acceder a cursos online masivos y gratuitos. unedcoma.es



Open Learning World. La materia se da exclusivamente en formato texto, pero tienen una amplia variedad de cursos disponibles. www.openlearningworld.com



Education Portal. Cursos en inglés. Combinan videos y texto. educationportal.com



Aula Fácil. Cursos en español en formato texto. Combinan videos y texto. www.aulafacil.com

Impulsa tu carrera Con estos datos ya puedes preparar tu propio plan de formación, hoy mejor que mañana. Recuerda que las oportunidades pueden aparecer en cualquier momento y tienes que estar preparado para explotarlas. La mejor arma que puedes tener es TU FORMACIÓN.

En cuanto a la formación gratuita para Jefes de Proyecto, te recomiendo dos: 

Pduotd. En este portal te informan de Webinar gratuitos sobre la dirección de proyectos, que además te ayudarán a conseguir los PDU necesarios para la renovación de la certificación PMI. www.pduotd.com



Projectmanager. Ponen a tu disposición un video semanal dónde profundizan en algún aspecto de la jefatura de proyectos, además de artículos, libros, plantillas, etc. www.projectmanager.com

www.proiectus.es

Número 1, Noviembre 2013

MIGUEL QUINTANILLA ERIKSSON Ingeniero de Telecomunicaciones con más de 10 años de experiencia en

empresas

TIC.

Actualmente

Director

General

Nuevas

Tecnologías

Telecomunicaciones en el Ayuntamiento de Las Palmas de Gran Canaria responsable de las áreas de Telecomunicaciones, Desarrollo de Aplicaciones, Smart City, Big Data, Administración Electrónica, Atención al Ciudadano y Organización.

LA DIRECCIÓN DE PROYECTOS TI EN LA ADMINISTRACIÓN LOCAL (I): ALCANCE Y COSTE Aunque el enfoque de este artículo está orientado a la ejecución de proyectos de tecnologías de la información (TI) en el ámbito de las administraciones locales de Canarias, es probable que el mismo sea extrapolable a la ejecución de otro tipo de proyectos (no solo de TI, ya que están afectos por las mismas normas) o la ejecución de proyectos en otros ámbitos (otros tipos de administraciones u otras regiones, ya que la mayor parte de las normas que los condicionan son de carácter nacional).

compras directas (cuando los importes están son inferiores a 18.000 €). En el marco de este tipo de proyectos se analizan en este artículo como afecta la legislación vigente a aspectos de la dirección de proyectos tales como la definición del alcance o la gestión económica del proyecto (especialmente en proyectos plurianuales) y la gestión del cronograma. ALCANCE DEL PROYECTO El área de conocimiento del Alcance tiene por objetivos principales la recogida de los requisitos y expectativas de los stakeholders del proyecto, definir qué es lo que se va a hacer y que no se va a hacer en el marco del proyecto, realizar una primera descomposición del enunciado del proyecto y controlar y verificar que dicho alcance se logra. En el caso de una administración pública, el documento de referencia por el que se rige el alcance del proyecto es el pliego de prescripciones técnicas (PPT), que se hace público en el momento de la licitación.

Para explicar cómo afecta la normativa por la que se rigen las administraciones públicas a algunas de las fases de la dirección de proyectos tomaremos como referencia contratos de servicios de más de 60.000 €, para los cuales la Ley de Contratos del Sector Público garantiza los principios de publicidad y concurrencia a través de procedimientos abiertos. Para contratos de menor cuantía, aunque no están obligadas a ello (los suelen hacer por mera eficiencia administrativa), las administraciones públicas suelen optar por procedimientos negociados sin publicidad o 33

www.proiectus.es

Número 1, Noviembre 2013

EL PPT es un documento diseñado por algún técnico especialista de la administración, aunque en algunos proyectos (para los que la administración no dispone de técnicos especialistas en la materia) la redacción de dicho pliego puede externalizarse en una empresa de consultoría. Es estos casos, la empresa que haya recibido el encargo de redactar el PPT deberá hacerlo con la máxima objetividad y no podrá, bajo ningún precepto, participar en el posterior procedimiento de licitación.

está contemplado en el alcance del mismo y casi nunca entra a un nivel de detalle de definición de paquetes de trabajo. El PPT se acompaña siempre de un pliego de condiciones administrativas particulares (PCAP) en el que se establecen, entre otros, los criterios de valoración de las ofertas (objetivos y subjetivos) y el plan de facturación del contrato, que en el caso de proyectos suele estar vinculado a entregables intermedios o a la finalización del mismo, según sea la magnitud del proyecto.

Los proyectos de implantación de TI en las administraciones públicas pueden ser de carácter horizontal para la administración (despliegue de una nueva herramienta de trabajo en red o de un nuevo servidor de correo electrónico y calendario) o de carácter vertical (la implantación de un sistema de información tributaria o de un sistema de gestión de expedientes sociales). En el caso de los proyectos de carácter vertical es imprescindible involucrar a los departamentos destinatarios de la tecnología a implantar ya que recoger desde un primer momento sus necesidades y aportaciones a la definición del alcance es determinante una correcta gestión del cambio. Los usuarios finales son, en este tipo de proyectos, uno de los stakeholders de mayor peso.

GESTIÓN ECONÓMICA DEL PROYECTO Previo a la licitación de un proyecto es necesario disponer del crédito suficiente para su ejecución en las partidas económicas adecuadas al tipo de servicio o suministro que se va a realizar (capítulo 2 o 6 del presupuesto de gastos según sea uno u otro). Las licitaciones pueden iniciarse sobre presupuestos aprobados con indicación de las partidas a comprometer (licitación que se inicia en el mes de mayo, con cargo al presupuesto de ese mismo año, habiendo identificado la partida a desinar al mismo) o

El PPT es un documento que generalmente expresa lo que la organización pretende lograr del proyecto (funcionalidades o servicios a cubrir), con qué tecnología (o elementos técnicos) y con qué características técnicas o niveles de calidad (volumen de transacciones, velocidad de respuesta,…). Rara vez los PPT recogen información de lo que NO se pretender conseguir con la ejecución del proyecto, es decir, lo que no 34

www.proiectus.es

Número 1, Noviembre 2013

pueden tramitarse de forma anticipada con cargo a presupuestos futuros.

departamento distinto, para las adjudicaciones realizadas en los últimos 4 meses del año, generalmente estas partidas económicas no son reutilizables y se pierden, pudiendo incluso afectar al techo de gasto global de la entidad (ya que este se calcula sobre la base del presupuesto total ejecutado en el ejercicio y este tipo de ahorros se entienden más como una inejecución que como una gestión eficiente del presupuesto). Por este motivo es muy importante que, en la fase de elaboración de los pliegos se determine un precio máximo de licitación ajustado a la realidad del mercado, que permita competir a un número suficiente de empresas para que no deje margen para bajadas económicas excesivas.

En el primer caso, el documento que acredita la disponibilidad de crédito es la RC (reserva de crédito) que se debe realizar por el importe máximo previsto de adjudicación. En el segundo caso, que suele utilizarse para la contratación de proyectos que por algún motivo deben comenzar en el primer trimestre del año, la tramitación se inicia realizando una RC de futuro, si bien la posterior ejecución del proyecto (aun estando este adjudicado) dependerá de la disponibilidad final de presupuesto. Para el caso de proyectos plurianuales se procede a la reserva del presupuesto correspondiente al primer ejercicio, el resto quedarán supeditados a la existencia de crédito (podría incluso cancelarse el proyecto en la segunda o tercera anualidad si no hubiese disponibilidad presupuestaria). En el escenario actual de control de la estabilidad presupuestaria, en el que los techos de gasto en capítulo 2 y 6 se establecen con reducciones que oscilan entre un 5% y un 10% con respecto al presupuesto EJECUTADO del año anterior no es recomendable comprometer presupuesto por encima del 70% con carácter previo, especialmente cuando se trata de proyectos plurianuales.

Durante la ejecución del proyecto el director de proyecto debe hacer especial énfasis en el cumplimiento de los hitos asociados a facturación (esta tarea obliga a poner especial atención en el cumplimiento del cronograma, el alcance y la calidad), al menos en relación con los hitos asociados a cada ejercicio económico, ya que un retraso en la facturación del proyecto puede tener como consecuencia un grave descuadre presupuestario para la unidad administrativa o incluso el área de gobierno (en función de la magnitud del proyecto).

Cuando un proyecto se adjudica con una bajada económica sobre el precio máximo de licitación, por ejemplo de un 15%, es importante mencionar que dependerá del número de meses que resten del ejercicio para que dicho ahorro económico pueda ser reinvertido en otro proyecto dentro del mismo departamento o transferido a un

Las Administraciones Públicas tienen los presupuestos anualizados y vinculados a partidas presupuestarias. Todas aquellas 35

www.proiectus.es

Número 1, Noviembre 2013

partidas que no hayan sido ejecutadas dentro de un ejercicio se destinan a la amortización de deuda u otros usos prioritarios dentro del ejercicio (son los denominados remanentes) pero no retornan al presupuesto del departamento en cuestión. Esto significa que si teníamos previsto facturar 50.000 € de un proyecto en el mes de diciembre pero el proyecto va retrasado y no logramos cumplir el hito hasta el mes de febrero del año siguiente, los 50.000 € deberán abonarse con cargo al presupuesto del segundo año, lo cual supondrá una merma en la capacidad de ejecución de proyectos del departamento afectado.

www.proiectus.es

Número 1, Noviembre 2013

MONICA KHIANI ASHOK Directora de Proyectos certificada PMP® (Project Management Professional). Actualmente trabaja como Project Manager en GFI gestionando la implantación

de un nuevo sistema informático en el sector Sanitario de la Comunidad Autónoma de Canarias. Anteriormente, vivió en los Estados Unidos, trabajando durante 9 años en la compañía farmacéutica multinacional Pfizer en Connecticut y Nueva York, gestionando proyectos TI para uso en las fases pre-clínicas y clínicas del desarrollo de medicamentos.

GESTIÓN DE PROYECTOS, ES IMPORTANTE SEGUIR UNA METODOLOGÍA Desde el principio de los tiempos, todo proyecto, tanto profesional como personal, tiene que seguir unos pasos fundamentales y necesarios para poder completarlo con éxito. Por ejemplo, no se puede diseñar bien un programa si no se han analizado las necesidades del cliente, así como para poder tener una boda, hay que seguir ciertos pasos para planear el evento, no se puede llegar al día de la boda sin haber reservado el lugar del evento, sin haber decidido los detalles como decoración, etc.

Lo que más me sorprende, es que aun hayan empresas, grandes, medianas o pequeñas, que decidan realizar y gestionar un proyecto sin seguir ningún protocolo, metodología o disciplina. Quizás sea por creer que ello conlleva un coste muy alto, por no ver la necesidad de seguir ningún protocolo, metodología o disciplina, por no ver el beneficio, o simplemente por la ignorancia de la existencia de metodologías o disciplinas para la mejor gestión de proyectos. Si he aprendido algo en mis 14 años de experiencia profesional, es que todo proyecto, independientemente del sector en el que estemos, tamaño del proyecto, o prioridad, debe seguir unos pasos previamente definidos y acordados a nivel general en la empresa o dentro del mismo departamento. Si no hay un marco de trabajo definido nos encontraremos con que cada uno hace las cosas de una manera diferente, con desorganización y caos, y con toda probabilidad, aunque llegue a completarse, supondrá un mayor coste, un

Llevamos años definiendo y mejorando los procesos para conseguir realizar y gestionar un proyecto de la forma más eficaz, dependiendo del sector, tipo de proyecto, la prioridad del proyecto, así como la normativa que deba cumplirse según el sector o la industria. Para ello, tenemos a nuestra disposición multitud de herramientas, metodologías y disciplinas que nos ayudan a realizar y gestionar los proyectos de una manera más organizada, estandarizada y con un resultado final con menos probabilidades de fracaso. 37

www.proiectus.es

Número 1, Noviembre 2013

mayor empleo de tiempo y un producto final o servicio de menos calidad.

Control, y Cierre. La aplicación de estos procesos es iterativo, por lo que hay procesos que se repiten durante la vida del proyecto. Además, los procesos están interrelacionados al tener, generalmente, las salidas de un proceso como entradas del siguiente proceso.

Tenemos a nuestra disposición un abanico de metodologías y disciplinas para la dirección, gestión y ejecución de proyectos que han ido evolucionando con el tiempo. Hay metodologías ágiles como por ejemplo Scrum o Kanban, y metodologías predictivas, como PRINCE2 y la definida por PMI (Project Management Institute) en la Guía PMBOK® (Project Management Body of Knowledge), la cual es una metodología más tradicional. Dependiendo de la prioridad y tipo de proyecto, se utilizará una metodología ágil o predictiva. En este artículo nos concentraremos en la metodología más tradicional y clásica de PMI, definida en el PMBOK®, que es la base de las metodologías de gestión de proyecto. El resto, como Scrum, nacieron para solucionar algunas debilidades que se encontraron en las metodologías predictivas.



Contiene también 10 áreas de conocimiento: Gestión de la Integración, Gestión del Alcance, Gestión del Tiempo, Gestión de los Costos, Gestión de la Calidad, Gestión de los Recursos Humanos, Gestión de las Comunicaciones, Gestión de Riesgos, Gestión de las Adquisiciones del Proyecto y Gestión de Interesados.



Sobre esta matriz, se definen 47 procesos a lo largo de la vida del proyecto, cada uno con sus entradas y salidas, con las diferentes herramientas y técnicas disponibles, por ejemplo:

PMBOK®, según PMI, describe buenas prácticas para la Gestión de Proyectos que reúne años de experiencia de multitud de profesionales y se ha convertido en el estándar mundial para la práctica de la gestión de proyectos. También guarda correlación con las disciplinas de Gestión de Programas y Gestión de Carteras. Por supuesto, el desarrollo de esta metodología esta siempre en continua evolución. Planificación – Gestión del Alcance – Recopilar requisitos

PMBOK® es independiente de la industria o del sector del proyecto y define: 

No quiere decir que se tenga que seguir todos los pasos, procesos y entregables que define el PMBOK®, sino que define las mejores prácticas a seguir para la exitosa ejecución de un proyecto. Dependiendo del

Cinco grupos de procesos principales que cronológicamente corresponden con la vida de un proyecto: Iniciación, Planificación, Ejecución, Seguimiento y 38

www.proiectus.es

Número 1, Noviembre 2013

sector, tipo de proyecto o la prioridad del proyecto, se puede seguir un subconjunto de lo descrito en el PMBOK®. Pero esto debe ser estandarizado dentro de la misma empresa o departamento, para que así todo proyecto siga las mismas pautas, sobre todo si es una empresa de tamaño pequeño o mediano, donde puede que no exista un OGP (Oficina de Gestión de Proyectos).

del proyecto para no caer en la trampa de ir cambiándolo sin previo acuerdo entre las partes ,afectando los tiempos y costes del proyecto.

Mi experiencia me ha enseñado lo importante que es seguir una metodología para la ejecución de un proyecto, o de lo contrario nos veremos con algunos de los siguientes problemas que probablemente sean la causa del fracaso de muchos de ellos: 

Objetivos no bien definidos: Es muy importante definir claramente los objetivos, documentarlos y acordarlos con el cliente. Los objetivos del proyecto deben ser claros, medibles y alcanzables. Si no se sabe lo que se quiere alcanzar, no se puede planear las tareas y organizar los esfuerzos de los recursos implicados.



Tiempos no preestablecidos: El no establecer tiempos para cada tarea y documentarlo en un tipo de cronograma para el conocimiento de todos los implicados en el proyecto, puede alargar el proyecto indefinidamente, afectando el alcance y los costes del mismo.



Alcance no definido: El no definir bien el alcance de un proyecto entre las partes implicadas, tiene como consecuencia lo que se conoce como “Scope Creep” o Síndrome del Lavadero/Deformación del alcance del proyecto. Hay que tener bien claro y documentado, junto con el cliente y todas las partes implicadas, el alcance



Requerimientos incompletos o incorrectos: Donde dije digo, digo Diego. Si estos no son claramente definidos y acordados con el cliente y todas las partes del proyecto, puede que acabemos con un producto final que no se asemeja a lo requerido por el cliente, o al no haber acordado formalmente los requerimientos, estos pueden resultar infructuosos.



Aumento en costes: Los costes generalmente aumentan como consecuencia de varias variables del proyecto, como tiempos no preestablecidos, un alcance no definido o que cambia a lo largo del proyecto, requerimientos infructuosos, o no tener los recursos adecuados desde un principio.

Algunos, si no todos de los problemas aquí descritos, puede que sean obvios para muchos de nosotros, pero aun así hay empresas que no se dan cuenta de la posibilidad de estos problemas hasta que ya es muy tarde. Vistos en esta situación y llegados a un punto donde se ha completado más de la mitad del proyecto, las dos opciones con las que se enfrentan son, parar y dar el proyecto por fracasado (con la pérdida de tiempo y dinero que ello conlleva más el trabajo que habría 39

www.proiectus.es

Número 1, Noviembre 2013

que realizar para dar marcha atrás a lo ya implementado si fuera necesario), o seguir adelante invirtiendo más dinero. En conclusión, toda persona que tenga conocimientos de metodologías de gestión de proyecto, tiene la responsabilidad de imponerlo en aquellos que parecen no ver la luz (los beneficios a largo plazo). La integración de esta metodología en la empresas puede ser algo complejo y difícil debido al cambio necesario en la cultura, manera de trabajar e incluso de pensar. Pero es nuestra responsabilidad, como “Project Managers”, hacer llegar nuestros conocimientos al resto del mundo, y hacerles ver los beneficios a largo plazo. Por último, con relación a la Gestión de Proyectos, añadir que en Septiembre del 2012 se publicó ISO21500, una norma reconocida internacionalmente que documenta las buenas prácticas para la gestión de proyectos basada en el PMBOK®. Esta puede ser empleada por cualquier tipo de empresa u organización, pública o privada, para cualquier tipo de proyecto, ya sea complejo o no, grande o pequeño, de larga o corta duración.

www.proiectus.es

Número 1, Noviembre 2013

ANTONIO PEDRO DORTA ALONSO Ingeniero informático certificado Project Management Professional (PMP)®,

Máster en Administración de Empresas (MBA) y otra formación de posgrado. Más de 7 años de experiencia como consultor en proyectos de innovación tecnológica (ERP, CRM, EDI, E-Commerce).

GESTIÓN VISUAL EN GESTIÓN DE PROYECTOS Todo responsable de un proyecto se encuentra muchas ocasiones con una serie de preguntas que le abordan constantemente: ¿cómo va el proyecto?, ¿hay algo en lo que debería centrarme especialmente?, ¿sabemos todos los implicados cómo está progresando el proyecto?, ¿hay alguna tarea bloqueada?,… Se trata de preguntas muy habituales, que suelen englobarse dentro de los procesos de gestión del trabajo y su seguimiento.

Analizando esta definición improvisada, podemos extraer las siguientes conclusiones: 

Utiliza mecanismos y procedimientos. No basta con diseñar un cuadro de mandos sobre el trabajo de un proyecto, es necesario establecer pautas para revisar su contenido de manera periódica y tomar decisiones al respecto (reuniones de seguimiento).



Comunica el estado y progreso de un área, proceso o proyecto. Se trata de una técnica que podría aplicarse a una parte de un proyecto (a una fase o a un tipo de trabajos, como por ejemplo, implementación de código en un proyecto informático). También podría aplicarse a toda un área o incluso a toda una organización, si fuera conveniente.



Emplea símbolos y gráficas. El objetivo de esta herramienta es una consulta rápida y ágil. Un informe de 100 páginas cumpliría otros aspectos de nuestra definición, pero no éste.



Disponible en lugares de fácil acceso y consulta por parte de todos los implicados. Se trata de una herramienta

En este aspecto de la dirección de proyecto, es posible incorporar técnicas efectivas de otras disciplinas como la gestión de procesos o la gestión de organizaciones en general. Una de estas técnicas, abordada en el presente artículo, es la denominada gestión visual o gestión visible (visual management). Fundamentalmente, si tuviéramos que definir la gestión visual de alguna forma podríamos hacerlo manifestando que consiste en utilizar mecanismos y procedimientos para comunicar el estado y progreso de un área, proceso o proyecto a través de símbolos y gráficas, y que dicha comunicación se encuentre en lugares de fácil acceso y consulta por parte de todos los implicados. 41

www.proiectus.es

Número 1, Noviembre 2013

para el trabajo colaborativo, para facilitar la interacción de todo el equipo de proyecto. Un cuadro de mandos o panel informativo que esté ubicado en una sala de reuniones que se visita una vez al mes pierde toda su efectividad.

su lugar), debe ser autoexplicativo en la medida de lo posible, debe permitir la mejora continua (estar en evolución constante) y debe centrarse en lo verdaderamente importante. Si tuviéramos que elegir un tipo de tablero visual con el que comenzar, elegiríamos sin lugar a dudas el tablero Kanban, por su extensa documentación existente y por su facilidad de uso. Ahondaremos en este tipo de tablero visual más adelante en este mismo artículo.

¿CÓMO DEBE SER UN TABLERO DE GESTIÓN VISUAL? Una de las características más interesantes de la Gestión Visual es su flexibilidad. Realmente este tipo de técnicas definen qué hacer y para qué hacerlo, pero no especifican en detalle el cómo. Este enfoque permite un mejor aprovechamiento de este concepto, una vez que se tiene cierta práctica en el uso de tableros visuales, pero lamentablemente supone una barrera para aquellas personas que desean construir su primer tablero y no tienen muy claro cómo hacerlo.

¿QUÉ VENTAJAS PRESENTA LA APLICACIÓN DE TÉCNICAS DE GESTIÓN VISUAL?

Fuente: www.flickr.com Autor: Dexter Mixwith

En cualquier caso, todo tablero visual debe cumplir con ciertas premisas predefinidas: debe facilitar el orden y la estructura (mediante secciones, todo dato debe estar en 42



Muestra el trabajo en progreso del proyecto. Una de las consecuencias elementales de emplear este tipo de técnicas es que permite conocer cómo está evolucionando el proyecto en cada instante.



Potencia el trabajo en equipo. La utilización de este tipo de herramientas facilita el conocimiento por parte de todo el equipo de trabajo de qué está haciendo cada miembro. Esto generalmente transmite una mayor sensación de pertenencia a un equipo con objetivos comunes, da la oportunidad a cada miembro de explicarle a sus compañeros qué está haciendo y con qué dificultades se está encontrando, y permite obtener feedback por parte del resto del equipo.



Facilita el conocimiento del proyecto por parte de todo el equipo de trabajo y reduce el déficit de información. Todo el equipo de trabajo puede tener una noción mucho más precisa de cómo está evolucionando el proyecto, lo que tiende a

www.proiectus.es

Número 1, Noviembre 2013

disminuir problemas producidos por la falta de comunicación. 

Facilita normalizar el trabajo, a través de una herramienta común de resumen y toma de decisiones.

bloqueos. Aquellas tareas que estén bloqueadas o a la espera pueden ser rápidamente identificadas y, si esta situación se prolonga en el tiempo, será un aspecto recurrente e ineludible en toda revisión del estado del proyecto.



Ayuda a identificar riesgos. Una visión conjunta del proyecto, sin caer en el exceso de detalles, permite al equipo de trabajo evaluar si las acciones de control de riesgos están siendo eficaces, si han aparecido nuevos riesgos y si los riesgos actualmente identificados están evolucionando de alguna manera.

A continuación mostramos en una tabla resumen la repercusión de cada una de estas ventajas en los procesos y áreas de la gestión de un proyecto. Para ello, consideraremos la clasificación propuesta por el Project Management Institute en la versión 5 de la Guía PMBOK® (Project Management Body of Knowledge):



Ayuda a identificar defectos en los resultados. Los defectos en los entregables del proyecto, así como los problemas de validación de alcance, serán más difíciles de esconder, y resultará más complicado que pasen desapercibidos.

COMENZANDO CON TABLEROS VISUALES: KANBAN



Un tablero Kanban es un tipo de tablero visual en el que se establece un conjunto de columnas para definir diferentes estados de las tareas, cada una representada con una tarjeta identificativa. Habitualmente un

Ayuda a detectar cuellos de botella y VENTAJA

ÁREA PMBOK®

PROCESO PMBOK® RELACIONADO

Muestra el trabajo en progreso del proyecto

Integración

- Dirigir y Gestionar el Trabajo del Proyecto - Monitorizar y controlar el trabajo del proyecto

Alcance

- Controlar el Alcance

Potencia el trabajo en equipo

Recursos Humanos

- Desarrollar el Equipo de Proyecto - Gestionar el Equipo de Proyecto

Comunicaciones

- Gestionar las Comunicaciones - Controlar las Comunicaciones

Interesados

- Gestionar la Implicación de Interesados

Calidad

- Realizar el Aseguramiento de la Calidad

Ayuda a identificar riesgos

Riesgos

- Controlar los Riesgos

Ayuda a identificar defectos en resultados

Alcance

- Validación de Alcance

Calidad

- Controlar la Calidad

Ayuda a detectar cuellos de botella y bloqueos

Recursos Humanos

- Gestionar el Equipo de Proyecto

Interesados

- Controlar Implicación de Interesados

Facilita el conocimiento del proyecto por parte de todo el equipo de trabajo y reduce el déficit de información Facilita normalizar el trabajo

www.proiectus.es

Número 1, Noviembre 2013

tablero Kanban comienza con tres columnas (con los estados Pendiente, En progreso y Realizado) pero es posible definir las columnas que se desee en cada caso. Las tarjetas van colocándose en las columnas según evoluciona su progreso.

pizarras, de murales o incluso aprovechando espacios en ventanales. Es importante ubicarlo en un lugar de fácil acceso y revisión (por ejemplo, en pasillos concurridos o en el fondo de salas de trabajo compartidas). En cualquier caso, cuanto más cerca esté de donde se realice el verdadero trabajo, mucho mejor. Un elemento importante a considerar es que debería permitir su lectura a dos o tres metros de distancia (esto evita utilizar textos o gráficas excesivamente pequeños, que podrían aprovechar mejor el espacio pero sin duda impiden tener una visión global del conjunto). Si se va a emplear texto manuscrito, es importante realizarlo con rotulador grueso y en mayúsculas para que resulte fácilmente legible. Es muy habitual emplear material diverso de papelería, como cartulinas y tarjetas adhesivas (Post-it®). La diversidad cromática (utilizar diferentes colores) también es un elemento importante. También es posible incluir informes impresos y colocados en el tablero empleando cinta adhesiva o chinchetas. Todos estos aspectos favorecen la creatividad, la participación de todo el equipo y transmite un mensaje de simplicidad a través de métodos rudimentarios que impide un perfeccionismo mal enfocado. Dicho de otro modo, se persigue un tablero compuesto del esfuerzo de todo el equipo y que resulte útil para la gestión, en lugar de una herramienta estética y elegante pero poco funcional.

Fuente: www.everystockphoto.com Autor: orcmid

Los tableros Kanban se han estado empleando en los últimos años como complemento a metodologías ágiles como Scrum. De esta forma, se ha dotado de una herramienta visual a las reuniones diarias de seguimiento (Scrum Daily Meetings). En dichas reuniones, cada miembro del equipo tiene un tiempo limitado (uno o dos minutos, generalmente) para explicar qué ha hecho el día anterior, qué se propone hacer en ese nuevo día y qué dificultades cree que se encontrará para ello. TABLEROS VISUALES FÍSICOS

Las principales ventajas de un tablero visual físico es que, si está estratégicamente ubicado, facilita su revisión por parte de todo el equipo, fomenta las conversaciones

Los tableros visuales físicos son un forma de establecer paneles de trabajo a través de

www.proiectus.es

Número 1, Noviembre 2013

espontáneas sobre el estado y progreso del proyecto y resulta muy fácil de implantar. Por otro lado, para determinados equipos de proyecto, un tablero físico puede presentar una mayor facilidad de uso que una herramienta informática.

pero que resulte muy fácil acceder a ellas y hacer uso de las mismas. De lo contrario, su uso intensivo en la organización se verá muy limitado. Hoy en día existe una multitud de herramientas para gestionar tareas en forma de tableros Kanban (Trello y Kanbanize son sólo dos ejemplos de ello). Puede resultar una forma rápida de poner en marcha este tipo de gestión en una organización. Las principales ventajas de un tablero visual digital es que permite su consulta en cualquier lugar (fuera de la oficina, por ejemplo), resulta mucho más fácil de actualizar que un tablero físico, facilita la revisión en equipos que no están localizados en un mismo lugar de trabajo o que no dispone de espacio en sus infraestructuras físicas o autorizaciones para hacer uso de ellas (no en todas las organizaciones se permite realizar „cambios en la decoración‟).

Fuente: www.flickr.com Autor: Chris Huffman

CONCLUSIONES La gestión visual permite establecer entornos de trabajo más productivos a través de reducir el déficit de información, potenciar el trabajo colaborativo en un equipo y facilitar la comunicación de todos los implicados. Se trata de una herramienta que, si bien no resuelve cualquier tipo de problema en un proyecto, sí puede facilitar enormemente su seguimiento y simplificar su gestión.

TABLEROS VISUALES DIGITALES Un tablero visual digital puede abordarse como un tablero Kanban o bien como un cuadro de mandos o dashboard. Es importante que sea fácilmente accesible empleando simplemente un navegador web (y, preferiblemente, que no esté centrado en uno en concreto) y que posea responsive design (adaptable a diferentes resoluciones, ideal para dispositivos móviles y tablets). Un aspecto importante de este tipo de herramientas es su usabilidad. Interesa que posea cierta flexibilidad en funcionalidades, 45

www.proiectus.es

Número 1, Noviembre 2013

ROBERTO GONZÁLEZ YUSTE Project Control Engineer en Noble Drilling, Ulsan (Corea del Sur).

Ingeniero Técnico Naval por la Universidad de Las Palmas de Gran Canaria. PMP®, Euro-engineer.

MIRA QUIÉN HABLA Comúnmente se dice que el jefe de proyecto, pasa un 90% de su tiempo comunicando: asistiendo a reuniones, reportando, etc. La pérdida de información o la sobre información, puede jugar un papel importante en el éxito del proyecto.

este debe iniciarse en una etapa temprana, ha de ser iterativa. Tanta como miembros interesados entran y salen a lo largo del ciclo de vida del proyecto. Los objetivos de desarrollar un plan de comunicación son:

Una comunicación efectiva pasa por planificar al detalle, las relaciones entre los miembros del equipo, quién reporta, qué se reporta y con qué frecuencia. De esta manera, conseguimos que los miembros del equipo se sientan integrados, alineando esfuerzos y con el sentimiento de que todos persiguen un mismo objetivo: El éxito del proyecto.



Que la información manera correcta.

genere de



En el momento adecuado.



Que llegue a las personas adecuadas.



Y con el impacto deseado.

Para ello se debe de contar con los documentos, que la dirección de proyectos ha tenido que desarrollar previamente: Plan de gestión de proyecto, lista de interesados y su nivel de influencia en el proyecto, políticas de la empresa, factores ambientales de la empresa. El Plan de Proyecto marcara las líneas generales sobre la manera en la que trazara la dirección de proyecto y como se va a ejecutar, monitorear, controlar y cerrar.

Fuente: FreeDigitalPhotos.net Autor: jscreationzs

La Lista de Interesados, nos indicara el número de personas que necesitan ser

La planificación de las comunicaciones, no es un proceso único en el proyecto, y aunque 46

www.proiectus.es

Número 1, Noviembre 2013

tenidas en cuenta en las comunicaciones a lo largo del proyecto, así como su nivel de influencia en el mismo, para tener en cuenta el nivel de información que se debe generar para cubrir o superar sus expectativas, en todo el ciclo de vida del proyecto.

proyecto. Demasiada información puede dejar al descubierto ciertas deficiencias o ciertas ventajas, que no deberían ser mostradas y la falta de información, puede generar desconfianza o la pérdida de oportunidades para alcanzar el éxito del proyecto.

Las Políticas de Empresa, nos indicaran los reportes internos que debemos generar para tener informado otros departamentos, y la propia dirección de la empresa (junta de accionistas, dirección general, otros jefes de proyectos, etc.). Los Factores Ambientales de la Empresa, son aquellos, que según qué proyecto pueden variar de unos a otros: país de ejecución del proyecto, cliente, terceras empresas y su localización, factores políticos de la empresa, etc…

Fuente: FreeDigitalPhotos.net Autor: David Castillo Dominici

Todos estos elementos deben ser analizados desde el inicio del proyecto, puesto que serán la base de otros muchos elementos.

Paralelamente, el jefe de proyecto tiene que analizar el número de canales de comunicación, que se deben de gestionar. De esta manera, no habrá filtraciones o comunicaciones no deseadas entre miembros del proyecto.

¿Y AHORA QUÉ? Ahora tenemos los elementos para sentarnos a desarrollar nuestro Plan de Comunicaciones, así que empecemos por analizar cuáles son los requerimientos sobre la comunicación, para así establecer los recursos necesarios a desarrollar los formatos, contenidos, distribución y almacenamiento de la información. Un exceso de recursos destinados a la información o la falta de mismo, puede ayudar o evitara que el proyecto sea un éxito.

Pongamos un ejemplo: Construcción de una pieza móvil inteligente. Este proyecto involucra a varios departamentos, además del cliente, subcontratas, etc. Una vez analizados los interesados, encontramos que éstos son:

Además, hay que definir la calidad de la información a desarrollar de manera que dicha comunicación contribuya al éxito del 47



Dirección general.



Cliente (localizado construcción).



Departamento de Administración.

fuera

del

país

www.proiectus.es



Departamento de Compras, Logística y Almacenamiento.



Otros jefes de proyecto.



Ingeniería.



Desarrollo Software (empresa subcontratada y localizada fuera del país de construcción).



Encargado de fabricación.



Encargado de montaje.



Seguridad Laboral.



Tercera parte Certificadora.

Número 1, Noviembre 2013

Otros de los elementos a tener en cuenta son la aplicación de la tecnología a la hora de establecer los medios de comunicación. Los reportes pueden ser generados en formato PDF, Excel, Word o impreso en papel, para una distribución tipo gaceta. También debemos definir si en las reuniones se usara video conferencia, una sala de reuniones o un despacho. Los formatos también deben ser definidos, y así evitar que cada interesado utilice un formato distinto y/o incompatible (por ejemplo, generar el cronograma con Primavera, cuando el sistema que se utiliza en la empresa de desarrollo de software es MS Project). También tendremos que definir la frecuencia con la que la información es generada y distribuida, para crear patrones y regularidad, con la que obtener mediciones en los avances y comparaciones con otros proyectos similares. Y si las reuniones son semanales, quincenales o trimestrales.

Tenemos una lista de interesados de 11 personas (consideramos cada departamento una persona, que podrían ser más y por lo tanto entrarían en la lista de interesados como tales). Así que los canales que tenemos abiertos, se obtendrían como resultado de aplicar la siguiente fórmula:

Una parte importante del plan de comunicaciones, es definir la posibilidad de tener que generar y distribuir, información en casos excepcionales: Por poner algún ejemplo, incidentes acontecidos o impactos en el proyecto por eventos de riesgos surgidos (conocidos o no). Debe quedar muy bien definido quien son los receptores de dicha información, la frecuencia de la emisión, así como los medios a utilizar.

55 canales de comunicaciones abiertos, que deberán ser gestionadas. Es en este momento que se debe definir y limitar, quien se comunica con quien y quien ha de generar y recibir determinada información.

Todo este análisis plasmado en papel será nuestro Plan de Comunicaciones. A partir de aquí, habrá que hacer un proceso iterativo por si tenemos que actualizar el Plan de Proyecto, el análisis de Factores Ambientales, el Listado de Interesados o las Políticas de la Empresa.

Por poner un claro ejemplo, la dirección general no pedirá al encargado de montaje los reportes de estado. Al igual que la empresa de desarrollo de software no se comunicara con los otros jefes de proyecto. Todos estos canales deben quedar reflejados en el plan de comunicaciones. 48

www.proiectus.es

Número 1, Noviembre 2013

IVÁN SAMUEL TEJERA SANTANA Ingeniero Superior de Telecomunicaciones por la Universidad de Las Palmas de Gran Canaria, Master Executive in Project Management por la Universidad de Valencia

e ingeniero

certificado PMP®, PSM®,

ITIL® y

SCJP®.

Iván

desarrollado su carrera profesional en multinacionales relacionadas con el sector de las Tecnologías de la Información, siendo actualmente gerente de su propia empresa de Consultoría y Formación en Dirección de Proyectos.

LA CLAVE DEL ÉXITO DE LOS PROYECTOS INTRODUCCIÓN

Ahora bien, antes de contratar a un piloto, la empresa se asegurará de que dicha persona dispone de la formación y experiencia necesarias. Para ello, por un lado, se le solicitarán certificados de horas de vuelo, acreditaciones profesionales y conocimientos aeronáuticos, y por otro lado, deberá demostrar sus habilidades y destrezas solucionando todo tipo de problemas en un simulador.

Durante más de una década he desarrollado mi carrera profesional trabajando en proyectos de consultoría tecnológica para empresas de reconocido prestigio tanto a nivel nacional como a nivel internacional. Pero a pesar de lo que pudiera parecer, incluso en estas empresas, muchos proyectos fracasan al no ser capaces de cumplir con las expectativas de los clientes. Y todo ello, a pesar de contar con presupuestos lo suficientemente holgados como para poder contratar a los mejores ingenieros y poner a disposición del proyecto los últimos avances tecnológicos.

¿Qué ocurría hasta hace muy poco tiempo a la hora de contratar un Director de Proyecto en el ámbito de las Tecnologías de la Información? Pues que las empresas seleccionaban estos perfiles basándose en su conocimiento de una determinada tecnología, en el número de proyectos realizados, en su expediente académico, etc., pero en ningún momento se planteaba la contratación de un profesional en Dirección de Proyectos.

Muchos son los factores que pueden haber influido en el devenir de estos proyectos, pero sin duda, la falta de liderazgo y de dirección se postula como una de las principales causas de que dichos proyectos no alcanzasen los resultados esperados.

En épocas de bonanza esto no suponía mayor problema para las empresas y los clientes, pues se toleraba cierto grado de fracaso en la ejecución de los proyectos.

Pongamos un símil, estaréis de acuerdo conmigo en que, al igual que un Airbus A380, para llegar a su destino, precisa de un piloto, un proyecto, para alcanzar sus objetivos, precisa de un Director de Proyecto.

Sin embargo, la situación económica actual ha cambiado la forma de pensar tanto de 49

www.proiectus.es

Número 1, Noviembre 2013

unos como de otros, los primeros porque no pueden permitirse los sobrecostes que supone no cumplir con los requisitos y los plazos establecidos por los clientes, y los segundos, porque se ven obligados a rentabilizar cada euro invertido en la ejecución de proyectos.

CERTIFICACIONES

En un escenario de este tipo, y como resultado de este “tira y afloja”, surge la necesidad de profesionalizar la figura del Director de Proyectos. Ya no basta con tener un título académico acorde con el sector dónde trabajemos sino que además se nos va a exigir experiencia y formación en Dirección de Proyectos.

En esa línea ha desarrollado varias certificaciones que permiten al profesional acreditar su experiencia en uno u otro ámbito, siendo objeto del presente artículo las certificaciones en Dirección de Proyectos:

El PMI (www.pmi.org) se ha esforzado durante los últimos años en estandarizar todo lo que tiene que ver con la gestión de proyectos, gestión de programas y gestión de portfolios.



PMP® (Project Management Professional) Demuestra que su poseedor dispone de la experiencia, las habilidades y el conocimiento necesario para dirigir proyectos.

La pregunta es: ¿y cómo demostramos de forma creíble ante una empresa o institución que contamos con dicha experiencia y formación para poder actuar como Director de Proyectos?



Las respuestas podrían ser múltiples y muy variadas, y el debate que podría generarse en torno a ello dar lugar a múltiples opiniones e interpretaciones. Pero en lo que sí estaremos conformes una vez más es que, si somos capaces de complementar la formación académica, con experiencia y formación en dirección de proyectos, no debería existir, a priori, motivo alguno por el que no pudiéramos optar a una posición de Director de Proyectos.

CAPM® (Certified Management)

Associate

Project

Permite a cualquier profesional que desee iniciarse en la dirección de proyectos, y que no reúna la experiencia necesaria para optar a la certificación PMP®, obtener una acreditación en Dirección de Proyectos. 

PMI-ACP® (Agile Certified Practitioner) Valida la habilidad de un individuo para entender y aplicar los principios y las prácticas ágiles en la dirección de proyectos.

Este es precisamente el objetivo que persigue el Project Management Institute (PMI) con sus certificaciones en Dirección de Proyectos, permitir que cualquier profesional pueda demostrar que tiene el conocimiento, la experiencia y las habilidades necesarias para dirigir proyectos.

En la siguiente página se detallan los requisitos necesarios para poder optar a cualquiera de las certificaciones anteriores:

www.proiectus.es

Número 1, Noviembre 2013

REQUISITOS CERTIFICACIÓN PMP® EDUCACIÓN

EXPERIENCIA

FORMACIÓN

Título de secundaria

5 años de experiencia – 7.500 horas.

35 horas de educación formal

Título universitario

3 años de experiencia - 4.500 horas

35 horas de educación formal

REQUISITOS CERTIFICACIÓN CAPM® EDUCACIÓN

FORMACIÓN

Título de secundaria

1.500 horas de experiencia en proyectos o 23 horas de educación formal.

REQUISITOS CERTIFICACIÓN PMI-ACP® EDUCACIÓN

Título de secundaria

EXPERIENCIA

EXPERIENCIA PROYECTOS ÁGILES

FORMACIÓN

2.000 horas de experiencia

1.500 horas adicionales de experiencia

21 horas de

trabajando en equipos de

en equipos de proyecto que utilicen

educación

proyecto.

metodologías ágiles.

formal

CONCLUSIONES Si supiéramos cuál es la clave del éxito de la Dirección de Proyectos, probablemente esta revista no tendría sentido alguno. Simplemente, pondríamos el piloto automático en nuestro Boeing 747, y esperaríamos a llegar a nuestro destino. Pero mientras que llega ese momento, como Profesionales en Dirección de Proyectos debemos continuar apostando por la formación como medio para ser mejores profesionales.

www.proiectus.es

Número 1, Noviembre 2013

CLAUDIA FERNANDA DEL TORO VARGAS Consultora especializada en mejora de procesos y dirección de proyectos, usando modelos, estándares y técnicas reconocidas (CMMI, ITIL, PMBOK, SCRUM, KANBAN, LEAN, 6SIGMA, entre otros). Postgrado en Gestión de Proyectos de Informática, experiencia en diversas industrias. Certificada PMP® desde Junio de 2008, ITIL en Octubre de 2010, SDI (Strengths Deployment Inventory) en mayo de 2011 y Scrum Master en Enero de 2012.

EN ESTE NÚMERO ENTREVISTAMOS A… JEFA DEL PROYECTO DE REVISIÓN DE LA TRADUCCIÓN DEL PMBOK® 5 AL ESPAÑOL El 31 de diciembre de 2012 el Project Management Institute publicaba la versión 5 del PMBOK® (Project Management Body of Knowledge o Guía de Fundamentos para la Dirección de Proyectos) en inglés.

No os puedo dar el detalle, pues tengo una cláusula de confidencialidad. Pero a groso modo, el objetivo es revisar la traducción al español del PMBOK® 5, realizada por una empresa que provee este servicio.

En paralelo, varios equipos de trabajo ya habían iniciado los trabajos de traducción del PMBOK® al resto de idiomas en qué está disponible la Guía.

El Comité de Verificación de la Traducción (Spanish TVC por sus siglas en inglés) debe asegurar la correctitud de la terminología y frases en el contexto. Esto es posible porque los integrantes del equipo tienen conocimientos en Dirección de Proyectos y en los estándares del PMI. El mayor aporte es el que hacen representando a su país, para asegurar que lo que se escribe se entiende de la misma forma en todas partes.

En este primer número hemos querido entrevistar a Claudia F. Del Toro Vargas, quién se ha encargado de liderar el proyecto de revisión de la traducción del PMBOK® 5 al español, junto a un equipo compuesto por 23 voluntarios de 12 países diferentes.

¿Quiénes fueron los stakeholders implicados en el proyecto?

CONTENIDO DE LA ENTREVISTA Antes de comenzar, agradecerte en nombre de quiénes estamos intentando que este proyecto salga adelante, la referencia que has tenido de querer participar en este primer número de la revista.

Los miembros del Comité de Verificación de la Traducción, el Jefe del Proyecto de la empresa de traducción, el jefe de proyecto en el PMI, El jefe de Publicaciones del PMI, el gerente de la empresa traductora, los consultores de la empresa traductora y el Jefe de Proyecto del Comité de Verificación. Adicionalmente, había contacto y

Para situar a nuestros lectores, ¿podrías describirnos el alcance del proyecto? 52

www.proiectus.es

Número 1, Noviembre 2013

coordinación con los jefes de proyecto de otros comités de verificación.

proyecto deja de aportar. Para sobrellevar esta situación, lo que se acordó es que se llamaba la atención una vez y si no había respuesta o se debía hacer un segundo llamado de atención se notificaba a la persona que se sacaría del equipo.

¿En qué consistió tu rol como directora de proyecto? Desde realizar una convocatoria ampliada para que la gente supiera de la oportunidad de voluntariado, hasta coordinar la revisión de todas las secciones que nos fueron entregadas, tanto del Comité de Revisión de la Traducción, como de la empresa de traducción. Como cualquier jefe de proyecto, hay negociaciones, llamadas de atención, felicitaciones, motivaciones, etc

El otro problema es cuando se presentan incompatibilidades entre miembros. Esto puede ser más delicado, pues lo que uno menos desea es tener un equipo con conflicto o que alguien se retire enojado del trabajo. Afortunadamente en nuestro caso, solo hubo discusiones menores. ¿Cómo se consensuó la traducción en un ambiente multicultural?

¿Cómo se elaboró el plan para la Dirección del Proyecto?

Es complejo. Se usaron varias estrategias. La Se dieron ciertas directrices primera es generar un a seguir y ciertos hitos que debate cuando se hace una lograr y a partir de aquí, se propuesta y por mayoría se generó el plan de proyecto toma una decisión. Sin que guiaría desarrollo del embargo esto no es posible trabajo. Dado que el equipo en todos los casos, sobre no se encontraba todo porque hay palabras y físicamente presente, la traducciones que generan Fuente: Project Management Institute estrategia -para casi todo el mucha polémica, esto no trabajo- fue realizar una sólo le pasa a los miembros propuesta, presentarla al equipo y recibir los del equipo, sino a las personas que leen el comentarios para complementarla. Luego PMBOK® y una simple propuesta puede formalizarla. generar intensos desacuerdos. En estos casos usamos la estrategia de “puedo vivir ¿Qué problemas surgieron durante la con eso”, es decir, preguntar si la propuesta ejecución del proyecto? realizada le genera tal descontento que no se puede vivir con ello, entonces seguimos En estos casos, el problema típico es cuando debatiendo, pero cuando la propuesta si bien una persona que se presentó como voluntaria y es seleccionada, en el transcurso del 53

www.proiectus.es

Número 1, Noviembre 2013

no es la ideal, pero se puede vivir con ello, podemos concluir el debate.

Usando estas herramientas, logramos una eficiente comunicación en el equipo, obviamente que esto requiere el compromiso de cada uno de los miembros para que funcionase y así fue.

En un proyecto dónde los miembros del esquipo están tan deslocalizados geográficamente, ¿cómo se gestionaron las comunicaciones? Usamos varias herramientas de apoyo, que por cierto, fueron definidas desde el inicio, pero hubo un periodo “de prueba” hasta que nos decantamos por una. En primer lugar usamos Google Groups para los debates. Llegaron a ser tantos que comenzó a volverse complejo de administrar en la casilla de correo. Así que definimos reglas de intercambio de mensajes. De esta forma, identificamos cada tema en el título, como debate, información, minuta, etc. Recomiendo esta práctica para cualquier equipo que necesite administrar una cantidad importante de mensajes de correo.

¿Cómo se realiza el proceso de validación de los requisitos y aceptación de la versión definitiva del PMBOK5?

Además, habían reglas para cada debate, donde quien lo iniciaba debía llevar el conteo de respuestas, informar la decisión, documentarla y cerrar el debate. Con esto pudimos tener un orden adecuado.

Se realiza una revisión final y completa por parte de la empresa traductora y otra por parte del equipo de Verificación de la traducción. Cuando ambas partes están conformes, se da la aprobación final.

Adicionalmente, usamos Trello para llevar la gestión del proyecto. Trello es una herramienta gratuita que permite generar tableros de trabajo con sus tarjetas (Kanban), de tal forma que el responsable de la actividad avanzaba la tarjeta hasta su término.

En muchos momentos, los centros REP se mostraron contrariados sobre cuando se liberaría la versión en castellano, si estarían disponibles los exámenes en español después del 31 de julio... todo ello generó mucha incertidumbre tanto sobre los centros educativos como sobre los propios alumnos, principalmente por la falta de información, ¿que nos puedes comentar a este respecto?

Fuente: www.trello.com

Finalmente, para no complejizar los contactos, la relación entre la empresa de traducción y el PMI, la llevaba yo como jefe de proyecto, de esta forma teníamos un solo canal de comunicación.

El examen se presenta en inglés, con ayuda en español. Esta ayuda ha estado siempre disponible. Incluso con el reciente cambio de examen. Lo que es importante tener claro es 54

www.proiectus.es

Número 1, Noviembre 2013

que el proyecto de Verificación de la Traducción y el proyecto de traducción de la ayuda, si es que existe como proyecto, no son llevados a cabo al mismo tiempo ni por los mismos equipos, por lo que al momento de leer la ayuda, pueden haber términos que el candidato a certificarse no comprenda o no los haya visto antes. Mi consejo es que se revise bien el glosario y se internalicen los significados en inglés y español, de esta forma, se puede presentar el examen sin que se presenten confusiones. Y ya para finalizar Claudia, y agradeciéndote nuevamente el que hayas querido colaborar con la revista, ¿qué ventajas consideras que aporta esta nueva versión respecto a la versión anterior? Hay mayor consistencia con los nombres, pues ahora es más claro que todas las áreas de conocimiento tienen un plan subsidiario llamando “Planificar el/la X cosa”, pero el mayor aporte fue generar una nueva área de conocimiento que se llama “Gestionar a los Interesados del Proyecto” donde se traspasaron algunos procesos que antes estaban en comunicaciones. De esta forma queda más claro qué se realiza en la Gestión de las Comunicaciones del Proyecto de lo que se realiza en la Gestión de los interesados del Proyecto, que está más orientado a gestionar y controlar los compromisos de los interesados. Antes había una confusión en el proceso de comunicaciones. Si me permites, impartí una charla sobre este tema y dejé disponible una presentación, que se puede ver y bajar en el siguiente enlace. Por supuesto, muchas gracias.

www.proiectus.es

Número 1, Noviembre 2013

ENTIDADES COLABORADORAS

www.proiectus.es

Número 1, Noviembre 2013

Esta publicación está disponible bajo Licencia Creative Commons Atribución-NoComercial-CompartirIgual 3.0 Unported (CC BY-SA 3.0). Usted es libre de compartir, copiar, distribuir, y comunicar públicamente la obra y hacer obras derivadas; bajo las condiciones de reconocer los créditos de la obra de la manera especificada por el autor o el licenciante (pero no de una manera que sugiera que tiene su apoyo o que apoyan el uso que hace de su obra), y si altera o transforma esta obra, o genera una obra derivada, sólo puede distribuir la obra generada bajo una licencia idéntica a ésta. Texto de reconocimiento de los créditos de la obra Se ha de indicar la fuente de la información (www.proiectus.es) y el nombre y apellidos del autor del artículo referenciado. ISSN 2340-9363 Lugar de Edición: Las Palmas de Gran Canaria Empresa Editora: IVAN TEJERA PROIECTUS S.L.U. URL: http://www.proiectus.es E-mail: revista@proiectus.es