2 strategies when you do not master the tools your team uses.

Sometimes you may be assigned as a project manager to a project that includes in its scope a technology that you know superficially or just do not know at all. What can you do? How can you be part of the project team, contribute positively and not be a blocker?

There is a parallel discussion that we could start about the deeply commented topic of the project manager and the level of technical knowledge she should have about the technologies used in the project. But this is something I want to let aside in this post and focus on the fact that ‘you have been assigned to the project’ for no matter what reason and you have to deal with it.

My basic strategy would be: in the short term focus on being a facilitator and trust the specialists. On the long run, if you are going to manage more projects of this kind in the future, improve your skills.

Focus yourself in being a facilitator.

You must understand what is your main role in the project and avoid doing something you are not prepared to do. Focus in helping the team work and in obtaining the best possible outcome of their efforts: remove obstacles, identify the causes of problems and help them finding the best solutions.

Improve your skills when the project situation allows it.

If you are going to face a similar situation in future projects or you are just like me, an insatiable seeker of knowledge that constantly looks for new tools for my toolbox, you can do a training on the techniques your team has been using in the project. The level of depth will depend on your interest and the kind of job you have to do.

What is your opinion? Do you face frequently this situation? How do you deal with it?

2 strategies when you do not master the tools your team uses.

5 ejemplos de contratos ágiles

Como comentaba en mi último post del año pasado, uno de los motivos del posible fracaso de la utilización de Scrum en las organizaciones es el no trabajar con ‘contratos ágiles’.

Este tipo de contratos busca principalmente dotar de flexibilidad a las relaciones contractuales entre proveedor y cliente, de forma que este aspecto de la relación se alinee con la dinámica de la agilidad en la gestión de los proyectos.

Modalidades de contratos ágiles

Hay muchas modalidades de contratos que incorporan esa flexibilidad en la relación cliente-proveedor. El objetivo principal es repartir el riesgo de forma razonable entre ambas partes. La forma de hacerlo, en pocas palabras, es fijar coste y plazos de entrega y permitir flexibilidad/variabilidad en el alcance. El cliente va sabiendo conforme avanza el proyecto qué es lo que va a querer como resultado de su proyecto y el contrato debe permitir moldear el alcance conforme el proyecto avanza beneficiando a ambas partes y priorizando la entrega de valor para el cliente por encima del cumplimiento de un plan. Voy a enumerar y explicar brévemente algunos tipos de contrato ágiles  que conozco:

  • Money for nothing, change for free; el cliente puede cancelar el proyecto en cualquier momento pagando al proveedor un porcentaje del alcance cancelado. Cualquier funcionalidad puede cambiarse por otra de igual peso.
  • Time and materials iterativo e incremental; entregas funcionales al final de cada sprint. Posibilidad de terminar el contrato en cualquier momento (con o sin coste).
  • Precio por función; incentiva la entrega de software funcional cuanto antes. Los cambios son bienvenidos si se pagan.
  • Puntos y velocidad; calcula puntos y velocidad. Calcula el coste del proyecto en base a horas. Reduce el precio de horas y pon el resto en precio de puntos.
  • Compromiso agile; target time para MoSCoW. Mínimo y máximo agresivos. Por encima del máximo el proveedor pierde, por debajo del mínimo el proveedor gana. En el medio comparten costes y beneficios al 50%.

Recomiendo la revisión de esta presentación de Proyectalis y esta otra de Peter Stevens donde se analizan en profundidad las características, riesgos y beneficios de estas formas de contrato y algunas más.

¿Y todo esto por qué?

Pues, como decía al principio, para evitar movernos en el triangulo de hierro que acostumbra a perjudicar al proveedor y entrar en una dinámica de ganar-ganar en la que ambas partes salgan beneficiadas.

¿Utilizáis contratos ágiles en vuestras organizaciones? ¿qué tipos de contratos empleáis? ¿cuáles son los resultados? ¿estáis satisfechos?

5 ejemplos de contratos ágiles

Cloud computing: marketing e incertidumbre

La pasada semana he asistido a un evento sobre cloud computing organizado por un conocido grupo de comunicación en el sector de las TIC. Este es un tema que me interesa especialmente porque creo que es el futuro. Sin embargo, siendo un concepto muy tratado, cada organización puede aproximarse a él de formas muy diversas.

La nube: el concepto

El cloud computing se basa en la facilidad de acceso a sitios remotos que hoy en día proporciona internet. El concepto engloba la provisión de aplicaciones, datos, almacenamiento e infraestructuras de forma transparente para el usuario, que no precisa conocer ni la configuración de los sistemas ni su ubicación física.

, via Wikimedia Commons”]

La nube proporciona transparencia y flexibilidad al usuario final. Eso es bueno para “organizaciones líquidas”, concepto que he conocido a través de Jaime García Cantero (@jaimegcantero), que es en lo que se están convirtiendo nuestras empresas progresivamente: con límites y formas cambiantes, cada vez menos definidos y en constate trasformación.

Como he apuntado antes, no hay una única forma de consumir el cloud computing. Cada organización deberá adaptarlo a sus propias necesidades y circunstancias: habrá quien contrate aplicaciones como servicio, quien busque sistemas de almacenamiento ubicuos y flexibles, quien desee mantener servicios como el correo electrónico bajo su control directo o quien lo contrate como servicio a grandes proveedores como Google, quien virtualice, quien comparta servidores con otras organizaciones y quien trabaje con su nube privada.

, via Wikimedia Commons”]

En cualquier caso, creo que la mejor forma de aproximarse al tema es analizando servicio a servicio todos los que son prestados por el departamento de TIC, considerando sus necesidades de disponibilidad, su criticidad, las normativas legales que en cada caso apliquen, … y buscando un buen socio que nos acompañe en todo el proceso, asesorándonos sobre los mejores proveedores y la mejor estrategia a seguir.

Y es que el mercado de la nube está todavía poco maduro, en pleno crecimiento, como lo demuestra que el número y pelaje de los proveedores de cloud computing vaya en aumento día a día. Hay operadoras de telecomunicaciones, proveedores tradicionales de servicios de housing y hosting, grandes corporaciones internacionales, …

, via Wikimedia Commons”]

Y también hay mucho marketing. Se habla mucho de la nube pero, como pudimos comprobar en el evento al que hacía referencia al principio de la entrada, las empresas todavía la usan poco. No ocurre así con los particulares, ya muy habituados a gmail, dropbox, spotify, etc.

Incógnitas

¿Cómo evolucionará este mercado? ¿Quienes acabarán siendo los players principales? ¿Cómo se acabará segmentando? ¿Qué beneficios reales acabarán obteniendo las organizaciones? ¿Será suficientemente seguro?

Y yendo más hacia las afectaciones concretas de un departamento de TIC, ¿cómo afectará la nube a nuestra base instalada (nuestros activos)? ¿seremos capaces de convertir aplicaciones (cloud) estándar en aplicaciones de negocio (personalizadas)?

Y, en particular, los CIO y/o responsables del área de TIC, ¿serán capaces de transformarse de gestores de activos en gestores de servicios?

Conclusiones

En conclusión; mi impresión es que por ahora hay mucho marketing y demasiadas cuestiones abiertas.  Sin embargo, creo que es un camino que nuestros departamentos de TIC deberán transitar si nuestras organizaciones quieren seguir siendo competitivas. Habrá que ir poco a poco, dando pasos lentos pero firmes y tratando de ir resolviendo incógnitas por el camino.

Cloud computing: marketing e incertidumbre

Revisión de la arquitectura de aplicaciones

Para mucha gente, entre la que me encuentro, las vacaciones son un buen momento para reflexionar y dedicar tiempo a pensar en aquellos temas a los que el día a día no le deja tiempo. También es importante usarlas para desconectar.

En estas últimas semanas de agosto, sin entradas en el blog, he estado dedicando algunos ratos a pensar en la arquitectura de aplicaciones a la que me gustaría llegar en mi empresa en 1 o 2 años. En septiembre la empezaré a discutir con mi equipo.

Las capas de la arquitectura

La infraestructura de aplicaciones de una organización, esté estructurada o no, escrita en un documento o no, se organiza en 4 capas básicas, según el esquema siguiente:

Arquitectura de aplicaciones

De estas 4 capas, en esta entrada me interesan 2, la arquitectura de aplicaciones y la arquitectura de la información. La segunda se apoya en la primera, según se intuye en la figura.

La arquitectura de aplicaciones es básicamente lo que entenderíamos como el catálogo de aplicaciones con sus interfaces.

La arquitectura de información se basa en los flujos de información, las relaciones entre entidades de datos así como las herramientas y actividades que el negocio (capa superior) impone.

La arquitectura actual y la arquitectura objetivo

Para definir la arquitectura de aplicaciones yo utilizo básicamente 3 documentos:

  • Un inventario de aplicaciones por área funcional, estructurada en base a aplicaciones de planificación, de operaciones y de análisis.
  • Una descripción de la forma como estas aplicaciones se comunican entre ellas y con otros sistemas internos y externos.
  • Una descripción de cada aplicación y su razón de ser, incluyendo:
    • sistema
    • nombre
    • funcionalidades
    • plataforma en que se sustenta, …

Periódicamente es conveniente revisar la arquitectura de aplicaciones existente en base a:

  • cómo le afectarán los proyectos en curso o futuros que la organización tiene previstos.
  • qué aplicaciones se encuentran ya en la etapa final de su ciclo de vida

Estrategia y Plan de Migración

A partir de aquí se puede definir una estrategia de aplicaciones que nos marque qué aplicaciones cabe retirar, cuales deben ser actualizadas y dedicarles más recursos, en cuales debe ajustarse el nivel de servicio y los recursos empleados y en cuales, simplemente debemos seguir como hasta ahora.

A partir de la estrategia anterior ya estamos en condiciones de diseñar la arquitectura de aplicaciones objetivo (con los mismos documentos que hemos utilizado para definir la arquitectura actual).

Para llegar a esta imagen futura (que puede ser a 1, 2, o incluso 3 años vista) deberemos establecer un Plan de Migración, obtener recursos, presupuesto, … pero eso ya es otro tema.

¿Qué opinas? ¿utilizas un sistema similar en tu organización? ¿cómo documentas la arquitectura de aplicaciones?

Revisión de la arquitectura de aplicaciones

Primero una buena base

Recuerdo que cuando estudiaba Planificación de Sistemas de Información en el MGTI de La Salle nuestro profesor nos preguntaba con frecuencia si queríamos que nuestro departamento de TI fuera operativo o estratégico.

Su intención era convencernos de que el departamento TIC ideal debe ser capaz de ayudar a elaborar la estrategia corporativa y, sobretodo, debe ser un facilitador para llevarla a cabo. Debe existir un alineamiento entre el departamento de sistemas de información y la estrategia corporativa.

Hasta aquí todo bien. Este afán de ser estratégico es un objetivo ambicioso para cualquier departamento de TI. Es lo que nos gustaría ser de mayores. Pero primero lo primero.

El departamento debe ser capaz de cubrir primero las necesidades básicas de la organización en materia de TIC antes de intentar liderar y marcar la estrategia.

La primera cualidad del  responsable de sistemas, a mi entender, debe ser el pragmatismo. Es básico conseguir una infraestructura que asegure las operaciones y el día a día de la organización sin problemas. Cuando el departamento deja de pasarse el día apagando fuegos entonces puede empezar a dedicarse a tareas más elevadas como mejorar su conocimiento del negocio o mantenerse al día de los nuevos desarrollos tecnológicos.

Lo básico no es tan “interesante” como la definición de nuevos proyectos o probar nuevas tecnologías pero para un responsable de sistemas va a ser difícil convencer a la Dirección de la empresa de que implante un sistema de Business Intelligence si el departamento tiene dificultades para proporcionar a la organización un servicio de correo electrónico con un nivel de disponibilidad mínimamente razonable.

Pirámide de Maslow
Interpretación de la jerarquía de necesidades de Maslow

Es lo que John Baschab y Jon Piot definen como la pirámide de Maslow de las TIC en su libro The Executive’s Guide to Information Technology. Sin cubrir los niveles inferiores de la pirámide no podemos aspirar a la cumbre.

Y eso es algo que se olvida con frecuencia en muchos departamentos de TI. ¿Estáis de acuerdo?

Primero una buena base

Buenos propósitos para 2011

En estas fechas navideñas es típico repasar cómo nos ha ido el año; si hemos conseguido o no lo que nos habíamos propuesto y preparar un listado de buenos propósitos para el año próximo.

Creo que es bueno tener objetivos, a mi me sirven. Siempre que se hayan planteado bien.

Voy a compartir en este post algunos de mis objetivos a nivel profesional para 2011. Espero que el hecho de compartirlos públicamente me ayude a comprometerme más con ellos :

1. Certificarme como PMP.

Éste creo que es mi objetivo más ambicioso. Me estoy preparando por mi cuenta y tengo que hacer todavía la solicitud al PMI pero confío en certificarme dentro de 2011.

2. Mejorar mi formación en comercio electrónico y business intelligence (BI). Tengo especial interés en el BI porque lo veo como un punto de convergencia entre las dos áreas a las que me dedico profesionalmente; TIC y Gestión de la Calidad.

En mis últimos años en contacto con la dirección de mi empresa he observado la importancia de disponer de una buen Cuadro de Mando Integral. No basta con tener mucha información, hay que saber organizarla y gestionarla adecuadamente para poder tomar decisiones en base a ella.

La combinación de tecnología y aplicación de la estrategia de negocio me atrae especialmente.

3. Gestionar con éxito el que probablemente será el proyecto más importante de mi departamento (TIC) en 2011: la migración de nuestro ERP.

Este proyecto va a tener gran visibilidad en nuestra organización y quiero utilizar las mejores prácticas para llevarlo a cabo con éxito. Además, espero que me sirva como aplicación práctica del objetivo número 1.

Por supuesto hay muchos otros asuntos importantes en los que quiero mejorar profesionalmente, como lograr incrementar el aprovechamiento del sistema de gestión de la calidad que tenemos implantado,  pero creo que conviene tener un número adecuado de objetivos que nos permitan centrarnos y lograr su consecución.

Bueno, ya están expuestos. Son específicos, medibles, alcanzables (aunque retadores), realistas y están acotados en el tiempo.

Definiendo objetivos "smart" (en inglés)

A ver qué balance puedo hacer dentro de un año.

Hace unos días, uno de mis proveedores me envió la siguiente cita en su felicitación navideña: “que los problemas de año próximo duren tanto como los buenos propósitos navideños”. Tengo que reconocer que tiene un punto de realismo pero espero que no se dé en mi caso.

 

Buenos propósitos para 2011

Priorización de proyectos (PPM)

Cada semana me encuentro con compañeros, generalmente del área de Operaciones, que me solicitan la puesta en marcha de nuevos servicios o la mejora de determinados recursos. Muchas veces sus peticiones y sugerencias me parecen acertadas, porque conocen bien y tratan cada día a nuestros clientes y sólo buscan la manera de servirlos mejor. No obstante, tras comentar con ellos la idoneidad o no de su propuesta, les suelo acabar indicando lo mismo: éste no es el camino.

En las circunstancias económicas actuales, es más importante que nunca  una buena asignación de los habitualmente escasos recursos disponibles. No se trata sólo de hacer las cosas correctamente sino de hacer las cosas correctas.

Me explico; cuando se ha seleccionado un proyecto es necesario gestionarlo eficientemente (do things right). Pero antes de arrancar un proyecto y empezar a actuar como Project Managers alguien debe haberlo seleccionado de forma adecuada (do the right things) entre el siempre nutrido inventario de proyectos potenciales. Mi opinión es que esa decisión previa es fundamental para conseguir o no alcanzar los objetivos que se haya marcado nuestra organización.

El mencionado inventario es más conocido en el mundo del PMI como portafolio de proyectos y existe una metodología (PPM, Project Portfolio Management) que se orienta a garantizar que los recursos se asignen a los proyectos de acuerdo con la estrategia de la organización y maximizando el valor aportado.

Albert Cubeles, una de las personas a las que más respeto en el mundo de la Dirección de Proyectos describe muy bien una metodología a seguir. No creo que sea el único modo de hacerlo pero probablemente sea bastante acertado al estar basado en un conjunto de prácticas recomendables. En cualquier caso, ésta es probablemente la mejor oportunidad de contacto de un CIO o un Responsable de TIC con la estrategia corporativa.

Por mi experiencia y por las impresiones adquiridas en conversaciones con colegas de otras empresas, hay dos requerimientos fundamentales para que esta metodología sea exitosa y que no suelen ser fáciles de conseguir en empresas de tamaño medio: la implicación de la Dirección (no sólo del CEO sino de todo el Comité de Dirección) y la existencia de una estrategia definida para el conjunto de la empresa y para IT.

En muchos casos esta estrategia sólo está en la mente del CEO (especialmente en empresas pequeñas y/o familiares), y si está definida formalmente no trasciende del Comité de Dirección (al que el responsable de IT no siempre pertenece). Si se vence este primer obstáculo está la cuestión de la madurez de la organización en relación con la Dirección de Proyectos, que considero un paso previo para madurar en la gestión del portafolio de proyectos.

Como se puede ver el proceso requiere tiempo y esfuerzo, como todo lo que suele valer la pena, pero sus resultados probablemente compensarán la inversión realizada.

Priorización de proyectos (PPM)