Revista Proiectus Nº 1

DIRECCIÓN DE PROYECTOS

MADE IN CANARIAS

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

DIRECCIÓN DE PROYECTOS EN CONSTRUCCIÓN DE OBRA PÚBLICA

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

ww

w.p

roie

ctu

s.e

s

N

úm

ero

1,

Novie

mbre

2013

ISSN 2340-9363

http://www.proiectus.es/

2

www.proiectus.es Número 1, Noviembre 2013

DIRECCIÓN DE LA REVISTA

Iván Samuel Tejera Santana

[email protected]

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


Monica Khiani Ashok

Antonio Pedro Dorta Alonso

Roberto González Yuste

Claudia Fernanda del Toro Vargas

mailto:[email protected]



http://kr.linkedin.com/in/robertoyuste

3


5 ¿NOS PREOCUPAMOS POR LA DIRECCIÓN DE PROYECTOS?

Antonio Martel Rodríguez, PSM®

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

Eduardo Gutiérrez Bahillo

13 ¿BLANCO O NEGRO? ¿METODOLOGÍAS PESADAS O ÁGILES? ¿SCRUM O PMBOK?

Agustin Tapia Quesada

17 CÓMO HACER REALIDAD LOS SUEÑOS DE TU ORGANIZACIÓN

Manuel Vara González

20 IMPLANTANDO SCRUM EN LAS EMPRESAS

Juan Carlos Falcón Portillo

22 THE ITALIAN WAY

Davide Mazzanti

26 ¿GESTIONAS PROYECTOS TIC Y AÚN NO ERES ÁGIL? ¡MALGASTAS TU TIEMPO!

Raúl Herranz Serrano, PMI-ACP®

29 LA FORMACIÓN: TAREA CONTINUA

Vicente González Medina, PMP®

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


37 GESTIÓN DE PROYECTOS, ES IMPORTANTE SEGUIR UNA METODOLOGÍA

Monica Khiani Ashok, PMP®

41 GESTIÓN VISUAL EN GESTIÓN DE PROYECTOS

Antonio Pedro Dorta Alonso, PMP®

46 MIRA QUIÉN HABLA

Roberto González Yuste, PMP®

49 LA CLAVE DEL ÉXITO DE LOS PROYECTOS

Iván Samuel Tejera Santana, PMP®

52 ENTREVISTA: JEFA DE PROYECTO DE REVISIÓN TRADUCCIÓN PMBOK® 5

Claudia Fernanda del Toro Vargas, PMP®

http://www.linkedin.com/in/antoniomartel

http://www.linkedin.com/pub/eduardo-gutierrez-bahillo/37/844/950

http://es.linkedin.com/in/atapiaquesada

http://es.linkedin.com/in/mvara/es

http://es.linkedin.com/pub/juan-carlos-falcón-portillo/13/9b8/b64

http://www.linkedin.com/in/mazzantidavide/es

http://www.linkedin.com/in/mazzantidavide/es

http://es.linkedin.com/in/raulherranz

http://es.linkedin.com/in/raulherranz

http://es.linkedin.com/pub/vicente-gonzalez-medina-pmp/41/b58/b11

http://es.linkedin.com/in/miguelquintanilla/es

http://es.linkedin.com/in/monicakhiani

http://es.linkedin.com/in/tonidorta

http://kr.linkedin.com/in/robertoyuste

http://www.linkedin.com/in/ivantejera

http://cl.linkedin.com/pub/claudia-del-toro-v-pmp-itil-csm/23/3b4/257

4


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.

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.

Director revista PROIECTUS

Iván S. Tejera Santana

http://es.linkedin.com/in/ivantejera/

5


¿NOS PREOCUPAMOS POR LA DIRECCIÓN DE PROYECTOS?

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.

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?

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 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

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.

http://www.pmi.org

http://www.pmi.org

http://www.pmi.org

http://www.pmi.org

http://www.pmi.org

6


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.

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?

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?

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.

7


DIRECCIÓN DE PROYECTOS EN CONSTRUCCIÓN DE OBRA

PÚBLICA. EL PUESTO DE JEFE DE 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.

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.

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.

Entre los contratos con la administración, se

pueden distinguir, grosso modo, contratos de servicios, contratos de suministro y contratos

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.

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.

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.

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.

8


PROYECTO DE CONSTRUCCIÓN

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.

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.

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

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 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.

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

9


porcentaje por Beneficio Industrial

(habitualmente entre el 3 y el 8%)

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

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.

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

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.

La propuesta ganadora según el Órgano de

Contratación, procede a firmar el contrato con la administración.

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:

1 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.

10


Pliego de Bases Administrativas para la

Adjudicación.

Oferta del Contratista.

PPTP del Proyecto.

Planos del Proyecto.

Cuadro de precios 1 del Proyecto.

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.

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.

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

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”.

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.

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:

11


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 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 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 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

12


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.

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

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 PROIECTUS.

13


¿BLANCO O NEGRO? ¿METODOLOGÍAS PESADAS O Á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.

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.

El cuestionario del libro “Software

Engineering” de Sommerville, para valorar cuándo ser ágil o cuando usar métodos

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:

¿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

AGUSTÍN TAPIA QUESADA

Responsable de las Áreas de Desarrollo, Administración Electrónica, Turismo y

Sanidad de Open Canarias.

14


trabajo, cada situación requiere un modo

concreto de gestión.

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.

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.

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

proyecto). Bueno, a la documentación y a la

“explicitación” de lo que se documenta.

¿Es necesario hacer una Acta de una reunión

con el cliente? ¿es necesario reflejar los 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.

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

Revista PROIECTUS, Número 1, Septiembre 2013

15


acuerdo cuanto antes, no cuando el daño

esté hecho.

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?

¿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.

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

escorpión que picó a la rana, a veces sólo

escucha lo que quiere escuchar, y nuestra labor es que lo escuche todo.

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...

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?

16


Vamos, tenemos nuestros sentimientos,

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

¿Y el proyecto?

¿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?

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?

Entonces, ¿Cuando no habrá que invertir en

todas esas acciones preventivas y sólo en productivas?, pues eso, cuando tu equipo-cliente-proyecto te lo permitan.

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.

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...

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?


17


CÓMO HACER REALIDAD LOS SUEÑOS DE TU ORGANIZACIÓN

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.

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.

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.

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

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:

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.

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

Definir (Estrategias)

Implementar (Proyectos)

Operar (Resultados)

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).

18


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.

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.

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 “top-

down”, 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.

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).

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”.

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.

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.

Su aplicación dentro una organización, incluye la capacidad para:

Traducir la estrategia en términos

tangibles.

19


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 de los 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

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.

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

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)®.

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

Converting Strategy into Action, Ray Levitt.

Mastering the Integrated Program, IPS

Solutions.


20


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.

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.

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

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.

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.

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

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.

21


ellos, fue necesario pensar en las tareas

detenidamente; que debía realizarse primero, si estaba suficientemente desgranado para la posterior planificación etc.

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,

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.

22


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.

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.

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

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.

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

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.

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.

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

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.

http://www.thecoffeeroute.com/

23


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.

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.

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

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.

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.

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

Autor: Roberto Vongher

24


asombrosamente a un modelo de Lean

Production japonés.

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.

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

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.

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

25


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!

26


¿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

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 amplia experiencia profesional, Raúl complementa este

conocimiento con las certificaciones Scrum Manager, Certified Scrum

Professional y PMI Agile Certified Practitioner.

Fuente: Wikimedia Commons Autor: Almari Malave

27


es conseguir entregar el máximo valor a

nuestros clientes con los recursos disponibles (normalmente escasos).

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 sobre

documentación extensiva.

Colaboración con el cliente sobre

negociación contractual.

Respuesta ante el cambio sobre seguir un plan.

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

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).

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

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.

Fuente: Mountain Goat Software

28


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? (2009). Lean Enterprise

Institute, Inc.

The new new product development game

(1986). Takeuchi, H., & Nonaka, I.

29


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.

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.

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

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.

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

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.

30


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.

La empresa que busca cubrir un puesto de

trabajo valora entre muchos otros los siguientes aspectos de los currículum de los candidatos:

Experiencia y conocimientos que

disponga.

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:

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.

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

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.

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.

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

31


que fijes te servirán para encauzar tu carrera

profesional por donde más te interesa, explotando tus fortalezas y disminuyendo tus debilidades.

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.

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:

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.

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

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.

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.

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

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:

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

http://www.coursera.org/

32


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. education-portal.com

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

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

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.

http://www.edx.org/

http://www.unedcoma.es/

http://www.openlearningworld.com/

http://www.education-portal.com/

http://www.aulafacil.com/

http://www.pduotd.com/

http://www.pduotd.com/

http://www.projectmanager.com/project-management-resources

33


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).

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

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.

MIGUEL QUINTANILLA ERIKSSON

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

empresas TIC. Actualmente Director General de Nuevas Tecnologías y

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.

34


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.

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.

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

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.

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

35


pueden tramitarse de forma anticipada con

cargo a presupuestos futuros.

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.

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

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.

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).

Las Administraciones Públicas tienen los presupuestos anualizados y vinculados a

partidas presupuestarias. Todas aquellas

36


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.

37


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.

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.

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

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.

38


mayor empleo de tiempo y un producto final

o servicio de menos calidad.

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.

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.

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

Cinco grupos de procesos principales que cronológicamente corresponden con la

vida de un proyecto: Iniciación, Planificación, Ejecución, Seguimiento y

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.

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:

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

Planificación – Gestión del Alcance – Recopilar requisitos

39


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).

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

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.

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

40


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.

41


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.

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.

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

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).

42


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.

¿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.

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

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.

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

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

Fuente: www.flickr.com Autor: Dexter Mixwith

http://www.flickr.com/photos/dexter_mixwith/6353920353/sizes/m/in/photostream/

43


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

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

Comunicaciones - Gestionar las Comunicaciones - Controlar las Comunicaciones

Interesados - Gestionar la Implicación de Interesados

Facilita normalizar el trabajo

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

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.

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.

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.

Ayuda a detectar cuellos de botella y

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.

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):

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

44


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.

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

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

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.

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

Fuente: www.everystockphoto.com Autor: orcmid

http://www.everystockphoto.com/photo.php?imageId=6917310&searchId=39b32dd45982038aa5704ca2728334ee&npos=15

45


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.

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,

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‟).

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.

Fuente: www.flickr.com Autor: Chris Huffman

http://www.flickr.com/photos/chrishuffman/2336990347/sizes/m/in/photostream/

46


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.

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.

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

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:

Que la información se genere de la

manera correcta.

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.

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

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.

Fuente: FreeDigitalPhotos.net Autor: jscreationzs

47


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.

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…

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

¿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.

Además, hay que definir la calidad de la información a desarrollar de manera que

dicha comunicación contribuya al éxito del

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.

Fuente: FreeDigitalPhotos.net Autor: David Castillo Dominici

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.

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:

Dirección general.

Cliente (localizado fuera del país de construcción).

Departamento de Administración.

48


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.

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:

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.

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.

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.

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.

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.

49


LA CLAVE DEL ÉXITO DE LOS PROYECTOS

INTRODUCCIÓN

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.

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.

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.

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.

¿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.

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.

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

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 ha

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.

50


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.

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.

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.

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.

CERTIFICACIONES

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.

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:

PMP® (Project Management Professional)

Demuestra que su poseedor dispone de la

experiencia, las habilidades y el conocimiento necesario para dirigir

proyectos.

CAPM® (Certified Associate in Project

Management)

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.

En la siguiente página se detallan los requisitos necesarios para poder optar a

cualquiera de las certificaciones anteriores:

51


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 EXPERIENCIA EXPERIENCIA PROYECTOS ÁGILES FORMACIÓN

Título de secundaria

2.000 horas de experiencia

trabajando en equipos de

proyecto.

1.500 horas adicionales de experiencia

en equipos de proyecto que utilicen

metodologías ágiles.

21 horas de

educación

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.

52


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.

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.

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.

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.

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

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.

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.

¿Quiénes fueron los stakeholders implicados

en el proyecto?

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

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.

53


coordinación con los jefes de proyecto de

otros comités de verificación.

¿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

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

Proyecto?

Se dieron ciertas directrices

a seguir y ciertos hitos que lograr y a partir de aquí, se generó el plan de proyecto

que guiaría desarrollo del trabajo. Dado que el equipo

no se encontraba físicamente presente, la

estrategia -para casi todo el trabajo- fue realizar una propuesta, presentarla al equipo y recibir los

comentarios para complementarla. Luego formalizarla.

¿Qué problemas surgieron durante la ejecución del proyecto?

En estos casos, el problema típico es cuando una persona que se presentó como voluntaria

y es seleccionada, en el transcurso del

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.

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?

Es complejo. Se usaron varias estrategias. La primera es generar un

debate cuando se hace una propuesta y por mayoría se

toma una decisión. Sin embargo esto no es posible en todos los casos, sobre

todo porque hay palabras y traducciones que generan

mucha polémica, esto no sólo le pasa a los miembros

del equipo, sino a las personas que leen el

PMBOK® y una simple propuesta puede generar intensos desacuerdos. En estos

casos usamos la estrategia de “puedo vivir con eso”, es decir, preguntar si la propuesta realizada le genera tal descontento que no se

puede vivir con ello, entonces seguimos debatiendo, pero cuando la propuesta si bien

Fuente: Project Management Institute

54


no es la ideal, pero se puede vivir con ello,

podemos concluir el debate.

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.

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.

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.

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.

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.

Fuente: www.trello.com

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

definitiva del PMBOK5?

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.

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?

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

http://www.trello.com/

55


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.

http://es.slideshare.net/cdeltorovargas/cambios-con-el-pmbok-5ta-ed

56


ENTIDADES COLABORADORAS

http://www.laspalmasgc.es/

http://www.spegc.org

http://www.eii.ulpgc.es/

http://www.canariasexcelenciatecnologica.com/

http://www.clusteringenieria.com/

http://www.isidrohdez.com/

http://www.inventiaplus.com

http://www.inerza.com

http://www.desic-sl.com

http://www.contactel.es


http://www.opencanarias.com





















































































































































































57


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: [email protected]

Date post:	24-May-2015
Category:	Engineering
Upload:	pablo-aguilera
View:	104 times
Download:	0 times