Reclamaciones aceptadas

Esta entrada va de optimismo. Hoy me voy a dedicar a darle publicidad a algo que no ocurre tan frecuentemente como debería, que las empresas acepten tus reclamaciones de forma rápida.

El primer caso va sobre BT. Debido a mi regreso desde Gran Bretaña previamente a la finalización del contrato anual de ADSL, me habían cobrado una cantidad de penalización por cese prematuro del mismo. Tras indicarles que la razón de mi cancelación se debía a que no podían proporcionarme el servicio en mi nuevo hogar, pero que si fuera posible estaría interesado en seguir con ellos (tengo que decir que estaba muy contento con su servicio), han decidido devolverme el dinero cobrado inicialmente.

El segundo trata sobre un banco, que había emitido una tarjeta a mi nombre sin yo pedirla y que se ha encontrado durante más de un año en mi sucursal. Cuando les fui a visitar hace poco mostré mi interés sobre este tipo de tarjeta y me la proporcionaron, con lo que descubrí que me habían cobrado una comisión que no debían. Dicha comisión ha sido cancelada.

¿Alguno de vosotros tiene experiencias positivas en temas de reclamación de servicios que quiera compartir? ¿Qué método seguís en vuestras empresas/departamentos para gestionar las reclamaciones de los usuarios del servicio?

Integrando con Facturae

Hace unos días me descargué el programa de Gestión de Factura Electrónica disponible en Facturae que proporcionan los ministerios de Economía y Hacienda, y de Industria, Turismo y Comercio. La finalidad que tenía era valorar su posible utilización en los procesos de gestión de una empresa. El software está principalmente orientado a pymes y autónomos.

Hay una versión demo para trastear y familiarizarse, que incluye un conjunto de borradores de factura de prueba.

El programa está desarrollado en Java con una interfaz gráfica y almacena la información dentro de ficheros en formato separado por comas (CSV). La aplicación permite importar un conjunto de emisores, receptores, conceptos o facturas a partir de ficheros CSV.

A partir de esta información, las formas más sencillas para utilizar esta aplicación en conjunción con otras consiste en:

1) Forma rápida y no integrada: Generar con nuestra otra aplicación ficheros CSVs con los formatos requeridos por el programa de Facturae e importarlas después a la aplicación.

2) Forma de integración parcial: Gestionar desde nuestra aplicación directamente los ficheros CSV (por ejemplo utilizando un driver JDBC de los existentes). Posteriormente se firmarían los borradores con la propia aplicación.

3) Integración total: Disponer de una API (o estudiarlo a partir de los JAR disponibles) para hacer esta integración de forma automática. Mandé un correo solicitando esta funcionalidad y me han comentado que la incluirán próximamente para facilitar a los ERP esta integración.

Por otro lado, en el manual leo "Realizado con software abierto", lo cual no tengo muy claro si se refieren a que han hecho uso de bibliotecas de software abierto (lo cual es cierto mirando el directorio lib) o si el propio software que han desarrollado es también abierto. Al no haber una licencia incluida dentro del paquete y no poder descargar las fuentes, no puedo confirmar esta segunda opción.

Charlando con comerciales

Estoy en proceso de compra de un servidor pequeño, pero que permita un par de máquinas virtuales para una empresa y he estado charlando un rato con un comercial y un técnico de una empresa que proporciona este tipo de equipos. La atención muy buena, intentando recomendarme los servidores que parece que están soportados para la configuración de virtualización que quiero utilizar. Curiosamente el prefijo de la llamada es de Francia. Lo único que me parece que se les escapó es descubrir que VMWare ESXi se puede descargar de forma gratuita desde hace unos meses y la licencia no tiene límite de tiempo (aunque sí de funcionalidad). Intentando venderme las ventajas de Windows 2008 Hypervisor, he tenido que explicarles que algunos productos que utilizamos aún no dan soporte para windows 2008 (por lo que, en estos momentos, no me interesa pagar ese precio por el OS teniendo licencias para las VM con windows 2003).

¿Alguna experiencia de primera mano virtualizando con ESXi o con W2008?

Por otro lado, los comerciales de Orange han llamado por sexta vez en dos semanas al teléfono de mi "mother-in-law" (no le gusta que la llame suegra) a pesar de nuestras reiteradas negativas a sus ofertas de telefonía para su domicilio. Al preguntarles si me podrían retirar de la lista, el pobre teleoperador (me recuerda mis tiempos en Servicom) me ha dicho que podía quitarme de la suya, pero que quizá alguno otro de los compañeros... No he podido más que reirme y, esperando que la llamada quedara grabada indicar que con tal grado de informatización, seguro que para solucionar los problemas también te llaman seis personas (léase con tono irónico).

¿Estáis recibiendo muchas llamadas de operadoras de telefonía?

Ventaja de ser autónomo

Una de las ventajas de ser autónomo y de trabajar remotamente para tus clientes (salvo por las reuniones periódicas) es que tan pronto puedo estar en Madrid trabajando desde casa como me puedo ir a un destino cualquiera. Estos días estoy en Barcelona, en el Hotel Front Maritim que dispone de Internet en las habitaciones, por lo que tengo todas las herramientas que necesito (el móvil siempre va conmigo). He podido aprovechar y pasar a saludar a la gente de ATOS Barcelona, con los que coincidí en varios proyectos europeos.

Cambiando de tercio, el otro día utilizaba un formulario web para pedir un presupuesto a una famosa empresa de seguros en relación al seguro de responsabilidad profesional. Sin contestación tras una semana, empiezo a sospechar que no es que haya crisis porque la gente no quiera gastar, sino que las empresas prefieren no hacer negocio.

De vuelta en España

Pues ya me encuentro definitivamente en España tras estos casi dos años viviendo y trabajando en Reino Unido. Una experiencia positiva, de la que se aprende mucho.

Intentaré volver a mi periodicidad habitual en el blog, aunque no lo voy a tener fácil ya que estoy haciendo el curso online de gestión de proyectos de I+D+i del COIT (Mejora Continua en mi proyecto profesional) y evaluando si seguir de autónomo u optar por trabajar de jefe de proyecto en alguna empresa interesante.

Una anécdota graciosa es el correo recibido de un departamento de selección de una empresa de I+D en la que se refieren a mí como "Estimado/a Alfonso" para solicitarme mi certificado de notas. La verdad es que muchas veces no se dan cuenta de la imagen que algo como eso (despersonalización) puede proyectar hacia el exterior en relación con un departamento de RRHH. Respecto a solicitar las notas, me parece bien, aunque ya que estamos yo pediría también referencias de carácter.

Eso me lleva a otra anécdota también curiosa, en la universidad en la que estudié han migrado las bases de datos para centralizarlas en vez de tener cada escuela la suya. El resultado es que la mitad de mis notas no aparecen en la nueva base de datos, mi fecha de nacimiento ha cambiado y me tienen que sacar el certificado de la antigua BD (en casa del herrero ...). Más vale que comprobéis las vuestras. Eso sí, la gente de secretaría es muy agradable y están dispuestos siempre a proporcionarte una solución, lo cuál se agradece frente a la burocracia que te encuentras en otros sitios: chapeu!. Menos mal que tengo mi título de ingeniero y el resguardo de haber solicitado el de doctor, que si no estaría temblando ...

Rural Offshoring

El otro día me venía a la cabeza la idea de realizar offshoring en el medio rural y me pregunté a cuánta gente más se le había ocurrido antes. Mirando en Google veo que a muchos.

Este artículo me pareció especialmente interesante.

Futuro libro

El próximo Febrero (aún quedan unos meses) Wiley publica un libro interesante llamado Market-Oriented Grid and Utility Computing que no puedo evitar recomendar considerando mi contribución en el capítulo de Service Level Agreements in the Grid Environment.

No, no me llevo comisión.

Nota: Parece que han quitado la entrada de la web de Wiley, aunque ya veo que lo anuncian en Amazon

Más allá de la jubilación

Leyendo los comentarios de una noticia sobre los cazatalentos más influyentes, me ha resultado curioso encontrar un par de enlaces a sitios web estadounidenses orientados a trabajadores jubilados o cerca de dicho momento en busca de trabajo. Aunque en muchos casos esto se debe a necesidad, me parece muy interesante este tipo de enfoques para gente que quiere seguir manteniéndose activa.

Como ya comentaba en una entrada anterior la experiencia y capacidades de algunas de estas personas pueden ser de gran valor.

Lo que me pregunto es, ¿tendrían cabida este tipo de sitios web en España? ¿Verías interesante que un grupo de estas personas, con experiencia y contactos, proporcionaran servicios como coaching o consultoría de negocio?

Proyecto en la Feria de Valladolid

Esta semana se presenta en la Feria de Valladolid un proyecto que hemos completado para una administración pública española. El servicio presenta gráficamente las parcelas de diferentes comunidades de regantes sobre Google Maps, integrando los servicios de mapas ofrecidos por los ministerios españoles (SIGPAC y PNOA). A su vez, un portal ofrece un enfoque participativo a estas comunidades de regantes.

Project Assurance ¿El ojo fijo en tu nuca?

Vale, de acuerdo, no he podido evitar intentar crear un poco de controversia con el título. Pero me sirve de entrada para hablar sobre este tema de garantizar el correcto funcionamiento del proyecto recordando alguna anécdota del pasado.

Tengo que reconocer que, cuando hace ya siete años dirigía mi primer proyecto en una empresa de servicios (antes ya lo había realizado en una propia), me sorprendió tener a una persona que varias veces al día me preguntaba por el estado del proyecto y me solicitaba que comprobara si había tenido en cuenta determinados aspectos en los diagramas de MS project.

Cuando meses después un compañero tuvo problemas con su primer proyecto en esa misma empresa, descubrí que, aparte de no haberle proporcionado una formación en gestión, nadie había acudido a supervisar su avance.

Esto me llevó a descubrir dos aspectos de la época de las llamadas puntocom.

El primero era que, debido a la existencia de gran número de proyectos que había que llevar a cabo de forma inmediata, la necesidad de nuevos jefes de proyecto se cubría promocionando a gente sin suficientes conocimientos o experiencia en gestión (parece ser que no había tiempo para formarles) y sin alguien que les apoyara directamente (no había gente disponible). Entiendo que los salarios crecientes y la competitividad al final de la burbuja para sobrevivir como empresas hacía aún más difícil encontrar un equilibrio en estos factores.

El segundo aspecto que aprendí fue que actuar supervisando al jefe de proyecto no es una tarea fácil y que hay que comunicar de forma muy clara la existencia y finalidad de dicha supervisión y cómo ésta contribuye en el éxito del proyecto y, por tanto, en la reputación del jefe de proyecto.

En Prince2, esta supervisión se puede localizar en el rol de Project Assurance. Dicho rol tiene una doble cara:

• Por un lado, desde un punto de vista del usuario, el proveedor y el negocio, comprueba que el jefe de proyecto está siguiendo los estándares requeridos, ajustándose al business case, realizando los pasos necesarios, comprobando la viabilidad del proyecto en cada momento entre otros aspectos (en definitiva dirigiendo el proyecto correctamente), y establece así una certeza que de otro modo se basaría en la información proporcionada por el jefe de proyecto (convertido en juez y parte).
  
  
• Por otro lado, hay que entender que la función de dicho rol NO es la de un espía que se encuentra en el proyecto para criticar el mal hacer de un jefe de proyecto. Eso es una percepción errónea. Todo lo contrario. En caso de que la persona que desarrolla dicho rol encuentre que no se está llevando a cabo alguno de los aspectos previstos, ayudará al jefe de proyecto a tenerlo en cuenta y así conseguir que el proyecto sea exitoso.
  

La labor de "Project Assurance" en Prince2 es responsabilidad de la Junta de Proyecto que puede delegarla en terceras personas (nunca en el jefe de Proyecto). En este caso, si surgen diferencias de opinión sobre algún aspecto del proyecto se podrían escalar.

Cursos interesantes

Aunque ya no estoy de vacaciones, aún sigo cerrando flecos y preparandome para mi vuelta a España. A riesgo de hacer publicidad gratuita, un par de cursos interesantes que he visto anunciados en España son:

• Un curso de Scrum en Madrid por la empresa de Ángel Medinilla.
  
• Un curso online sobre Dirección de Proyectos para la Gestión de la Innovación y Proyectos I+D+i ofrecido para los miembros del COIT/AEIT.
  

Una idea que me rondaba por la cabeza es hablar con compañeros jefes de proyecto y gerentes para organizar seminarios conjuntos en el que presentarnos información sobre esta disciplina. Yo puedo empezar con alguna parte de Prince2. Ya veremos en qué queda.

Entrada vacacional

Me encuentro de vacaciones, preparando mi regreso definitivo a España, y por eso la falta de contenido últimamente.

Algunos artículos interesantes en relación a la gestión de RRHH y talento en la empresa:

• Artículo en Businesweek sobre un estudio acerca de la gestión del talento en función del tamaño de la empresa y donde comenta seis prácticas clave en dicho ámbito.
  
• CIO insight publica un artículo muy interesante sobre la falta de gestión de la formación y carrera de los trabajadores de los departamentos IT y cuáles son los principales obstáculos a dicha gestión y los riesgos a los que lleva.
  
• Este mismo sitio ofrece una presentación con claves sobre cómo retener a los mejores trabajadores del departamento IT.
  

Como decía, aún me quedan unos días más de vacaciones, por lo que esto seguirá un poco parado.

Plan de revisión del resultado del proyecto

¿En qué consiste el éxito de un proyecto? Cuando he preguntado a diferentes personas cómo valoran el éxito de un proyecto, me he encontrado con muchas respuestas distintas.

Las métricas clásicas de proyectos se centran en la consecución del plan de proyecto cumpliendo los requisitos iniciales. Desde mi punto de vista, no es lo mismo validar el éxito de un proyecto con el éxito del cumplimiento del plan. Si uno se centra en valorar estos aspectos de coste/tiempo/requisitos sin mirar el cuadro completo, se puede enfrentar a problemas como continuar un proyecto que ya no tiene sentido desde un punto de vista de negocio. Por eso el énfasis que algunas metodologías de gestión de proyectos, como Prince2, ponen en el Business Case actualizado como punto de referencia para la toma de decisiones a lo largo del proyecto.

Los objetivos de negocio del proyecto deberían ser los que marcaran si el proyecto ha tenido éxito o no, mientras que las métricas tradicionales pueden servir para mejorar la gestión de los proyectos en cuanto a buenas prácticas y metodologías, ayudado por el Informe de lecciones aprendidas. Desde esta óptica, Prince2 define el Post-project review plan que me ha dado por tradudir por Plan de revisión del resultado del proyecto. Este plan se genera al finalizar el proyecto, en la etapa de cierre del mismo. El jefe de proyecto define cuándo y cómo se ha de valorar si los objetivos se han cumplido. Para ello se han de observar los beneficios que se definieron en el BC y la foto inicial que se hizo de la situación del negocio al inicio del proyecto. Este plan ha de definir también qué personas serán necesarias para realizar esta validación, cuándo y por cuánto tiempo.

Tomemos como ejemplo un proyecto de posicionamiento Web. Uno de los beneficios definidos en el BC es que el porcentaje de visitas a la página a través de buscadores incrementará un 50% y las ventas un 10% al cabo de tres meses de finalizar el proyecto. En el plan de revision del resultado del proyecto se define que se requiere a un responsable de sistemas que compruebe dentro de tres meses los datos de visitas al sitio web que provengan de buscadores y compras realizadas por estos usuarios, lo cual le llevará 4 horas aproximadamente.

Otro elemento que ha de incluirse en la revisión de los resultados es la detección de posibles problemas que se hayan producido como resultado del proyecto, hablando con los usuarios (gente de soporte, por ejemplo) del producto del mismo.

La persona responsable de la revisión de los resultados y, por tanto, de comprobar que se lleva a cabo el plan se denomina en Prince2 el Executive que equivaldría de alguna manera al Sponsor de PMI.

Posicionamiento del blog

Hace unos meses, cuando empecé con este blog, quise hacer un experimento sobre posicionamiento web (SEO) del mismo siguiendo las recomendaciones de libros y webs. Dejando a un lado mis objetivos para las conversiones, voy a hablar un poco del tema de tráfico resultado de búsquedas.

El resultado actual es que un 40% de las visitas que recibe el blog provienen de búsquedas en Google (alguna en Altavista) y prácticamente ninguna de MSN o Yahoo. Cuil aún es demasiado joven. Respecto a los principales términos de las búsquedas no hay ninguna sorpresa, los que más competencia tienen son los que menos visitas atraen. El ranking (eliminando ego-searching y compañías/bitácoras buscando referencias a sí mismas) quedaría encabezado por arquitectura empresarial y sus variantes, seguido de planificación producto, búsquedas relacionadas con Prince2 y con business case acompañadas por términos en castellano. Curiosamente, realizando una búsqueda de esos términos en Google.es y Google.com los resultados varían entre la primera página y la segunda.

Una cosa que sospecho es que en la valoración de Google de enlaces a sitios web no se realiza una distinción entre tipos de enlaces, contando lo mismo alguien que realmente referencie a tu sitio web que un comentario que hayas dejado en otro sitio (otro blog, por ejemplo) de los que enlazan de vuelta a través de tu nombre.

¿Utilizáis técnicas de posicionamiento web para vuestro blog? ¿Qué términos son los que más llevan a vuestro sitio web? ¿Coinciden con los planificados?
Y ya para nota, ¿qué objetivos seleccionáis para las conversiones en un blog? ¿Tenéis páginas concretas a las que queréis llevar a vuestros lectores (web de empresa o página de contacto, por ejemplo)?

Métricas de proyectos y errores en proyectos IT

Hoy quiero hacer referencia a un par de artículos publicados en CIO.com que me han parecido bastante interesantes.

En primer lugar, publican un informe de Forrester en el que se comenta que utilizar las métricas clásicas de evaluación de éxito de un proyecto IT lo condena al fracaso. Estas métricas clásicas consisten en comprobar si se completó en tiempo, coste y cumpliendo los requisitos iniciales.


Lo que insinúa el artículo es que este tipo de valoración ignora la necesidad de cambios a lo largo de un proyecto debido, por ejemplo, a requerir una mayor calidad en el resultado final, o a modificaciones en el entorno como una nueva legislación. Estos cambios pueden suponer un incremento en el coste del proyecto o en el tiempo estimado para completarlo, pero a la vez pueden incrementar el beneficio obtenido por el proyecto. El artículo no propone cambiar dichas métricas sino que sugiere acciones que la oficina de proyectos debería realizar para mejorar el rendimiento del proyecto y comunicar su complejidad. Desde mi punto de vista, lo principal es valorar la aportación que el proyecto hace al negocio mediante el uso del business case como elemento de decisión para continuar un proyecto en las distintas etapas del mismo y su actualización en función de los cambios externos al proyecto (legislación, competencia, huelgas...) e internos al mismo (planificación demasiado optimista...).

El otro artículo hace referencia a los 14 errores más comunes en gestión de proyectos de los departamentos IT.

Interesantes también los comentarios de la gente que discuten sobre la validez o importancia de los mismos o de las soluciones propuestas y proponen algunos errores y soluciones alternativas. Los que comentan originalmente son:

• Carecer de los recursos correctos con la habilidades adecuadas para el proyecto.
  
• Falta de experiencia del director de proyecto.
  
• El departamento de IT no sigue un estándar o metodología de gestión de proyectos.
  
• IT pierde eficiencia y flexibilidad debido al uso de demasiados procesos.
  
• No se lleva un seguimiento de los cambios en el alcance del proyecto.
  
• Falta de información actualizada sobre el estado del proyecto.
  
• Ignorar los problemas.
  
• No definir inicialmente el alcance del proyecto en colaboración con la gente de negocio.
  
• No ver la relación y dependencias entre proyectos.
  
• No considerar la ley de Murphy (gestión de riesgos).
  
• Prestar escasa atencion a la gestión del cambio (quién ha de adoptar la tecnología).
  
• El plan de proyecto no está completo en cuanto a qué debe entregarse y cuándo.
  
• IT no discute fechas imposibles de cumplir sugeridas (o impuestas) por el CEO.
  
• Mala comunicación con patrocinadores y actores principales en cuanto a requisitos.
  

¿Cuáles de estos errores has encontrado en los proyectos IT de tu departamento? ¿Crees que existen otros más importantes? ¿Consideras que las métricas de evaluación de proyectos clásicas deben ser revisadas o cambiar al menos su importancia?

¿Se puede enseñar a emprender e innovar en las universidad?

Esa es la pregunta que plantea a los alumnos en este vídeo de una charla dada por Tina Seelig (profesora de la Universidad de Stanford) en un curso de la Universidad de California.



Dentro de la presentación, la profesora plantea diferentes actividades que ella ha puesto en práctica y que ayudan a la gente a tener una actividad más emprendedora. Explica que la actividad del emprendedor no tiene por qué dar como resultado la creación de una nueva empresa sino que puede aprovecharse dento de las empresas y que Google es uno de los principales interesados en los egresados de sus cursos.

Por otro lado, a través de ese vídeo llego a la web del Stanford Enterpreneurship Corner que ofrece varios vídeos con partes de conferencias dadas sobre estos temas.

¿Cuál es vuestra opinión al respecto? ¿Es posible enseñar a la gente cómo innovar o ser emprendedor?

Business Case II: Inversión y plazo

Hace unos cuantos días comenzaba a tratar las partes que componen el caso de negocio en el que se debería basar todo proyecto y hablaba de razones, opciones, beneficios y riesgos. Hoy finalizo la lista con los apartados más relacionados con la parte económica:

• Coste y Tiempo. Cuánto gastar y en cuanto tiempo se ha de completar cada una de las fases del proyecto para que el Business case tenga sentido. En un principio puede ser una estimación que se completará más adelante con la información extraída del plan de proyecto. Recordemos que ambos aspectos pueden estar sujetos a una cierta tolerancia.
  
• Valoración económica de la inversión ("Investment appraisal") . Realizar una análisis económico de los costes totales de realizar el proyecto incluido desde el desarrollo, hasta el mantenimiento y soporte, comparados con el valor financiero del beneficio producido durante un espacio de tiempo predefinido.
  
• Evaluación. Se ha de producir una evaluación final sobre si el proyecto es o no rentable dependiendo de los supuestos considerados inicialmente para asumir que los beneficios se completarán. Para ello se puede realizar un análisis de sensibilidad que nos dirá cómo de dependiente es el proyecto de la consecución de un beneficio concreto (o de que se cumplan determinados supuestos). Una opción alternativa es realizar un análisis GAP (Good, Average, Poor) ofreciendo tres predicciones distintas desde la mejor posibilidad hasta el peor escenario posible.
  

De nuevo hay que recordar que el Business case puede sufrir modificaciones a lo largo del proyecto pudiendo requerir actualizar alguno de sus apartados para comprobar si el proyecto es todavía viable.

¿Realizas Business Case de tus proyectos? ¿Qué otros aspectos consideras en ellos?

Presentaciones varias

En el sitio web de Parleys encuentro presentaciones interesantes como las de JavaPolis 2007. Entre ellas podemos ver:

- Project Anti-Patterns: How to make your project fail. Presentación que explica los secretos para hacer fracasar tu proyecto miserablemente, ya seas cliente, gerente de cuenta, jefe de proyecto, arquitecto, diseñador, desarrollador o "tester".
- Scrum in Practice for non-believers. No se puede decir que los presentadores sean muy amenos, la verdad, pero al menos explican su experiencia en el uso de Scrum.

¿Has aplicado alguna vez los "anti-patrones" explicados en la primera presentación? ¿Cuánta gente conoces en tu empresa que los aplique habitualmente?

Diez diapositivas para solicitar inversión en software

Hace ya unos días hablaba de un portal de vídeos de formación gratuitos que enlaza a diferentes sitios web. Uno de ellos es el de la Universidad de California Santa Barbara, donde podemos ver los vídeos de su programa de gestión de la tecnología.

En el vídeo adjunto (una hora) Ann Winblad, co-fundadora de Hummer Winblad Venture Partners, explica a los alumnos el tipo de empresas que financian, la diferencia entre disrupción e innovación, la necesidad de detectar esos elementos disruptores y, al final, explica las diez transparencias que esperan que se les presente cuando se les solicita financiación, especialmente en temas software. Sinceramente, muy entretenido.



Estas diez transparencias son:

1. Resumen ejecutivo. Debe explicar el problema que se intenta resolver y la ventaja diferenciadora. Ha de expresar cuál es la misión y muchas veces sirve para capturar la atención de los inversores.
   
2. Equipo. Quiénes forman el proyecto, su pasado y capacidades. No se financia un producto, financian a la gente que compone el equipo, el proyecto.
   
3. Análisis del mercado. Tamaño, posición y competidores. Explicar por qué tienen que invertir, que el mercado es grande, no sólo un nicho.
   
4. Ventaja competitiva principal. ¿Por qué se tiene dicha ventaja y por qué ahora es el momento de llevarla adelante?
   
5. Supuestos clave (<5 ó 6) que se han tomado en cuanta para asumir que el mercado es grande y el proyecto viable
6. Clientes (potenciales y referencias). Asumir el rol del cliente, si es posible haber hablado antes con ellos. ¿Cómo usarían los clientes el producto? Si se tienen ya clientes, entonces es para lucirte.
   
7. Plan de producto
   
8. Plan de ingeniería. Información técnica de cómo se llevará a cabo el desarrollo del mismo.
   
9. Modelo de ventas y resumen de márketing. ¿Cuánto pagarían los clientes? ¿Cómo se va a llevar al mercado? ¿Qué tipo de promoción se va a usar?
   
10. Modelo de negocio/Financias/flujo de caja. Desarrollar el plan de operaciones. Explicar por qué merece la pena invertir, el margen bruto, beneficio, revenue... Si no eres capaz de hacer esto, nunca recibirás financiación.
    

¿Has solicitado alguna vez inversión? ¿Contemplaste todos estos puntos? ¿La conseguiste?

Ideas e innovación abierta

El otro día descubría una iniciativa llamada Ideas4all, una especie de portal donde pretenden reunir un millón de ideas, que proporcione gente de todo el mundo. El tipo de ideas es de lo más variopinto y parece más la típica tormenta de ideas llevada a escala multinacional, pero sin centrarse en un problema concreto. Eso sí, puedes definir también problemas para que la gente sugiera soluciones, lo cual es interesante porque en algunos casos el problema o la solución puede mostrar nichos de mercado como la de encontrar un despertador individual para dormitorios compartidos.

Lo que más me ha llamado la atención es el tema de lo que puedes recibir a cambio. En principio, básicamente reconocimiento. Se pueden licenciar las ideas como Creative Commons Attribution o con una licencia en la que "teóricamente" puedes retener la propiedad intelectual, aunque te aclaran el las FAQ que no evita que alguien pueda copiarla y te dan consejos al respecto.

Por otro lado, hablaba el otro día en un comentario sobre el Observatorio Tecnológico de TID que se basa en la idea de innovación abierta descrita por Chesbrough mediante dos actividades: facilitando la llegada de ideas del exterior y haciendo que las ideas que no se puedan aprovechar internamente en TID en la actualidad se encaminen hacia nuevos mercados. En ese entorno se encuentra el blog La Cofa sobre vigilancia tecnológica.

Encuentra las cinco diferencias...

... entre el perfil de la persona que buscan las empresas y los estudiantes que salen de las carreras técnicas ICT.

Leyendo un artículo de Businessweek al que llego a través del Blog Salmón sobre los estudiantes de negocios en Reino Unido, me acuerdo de una charla que escuché hace unos años en unas conferencias en las que hablaba de por qué se había reducido el número de estudiantes de informática en EEUU.

Una de las razones que daba era el incremento de seguridad en su país, que había provocado una reducción del número de estudiantes extranjeros que iban a estudiar. Sin embargo, lo que realmente quería comentar era las otra razones:

1. Decepción de la gente que trabaja en el sector, que se transmite a los futuros estudiantes. Una de las razones para esta decepción es la falsa sensación recibida por los estudiantes a lo largo de la carrera de cómo se trabaja en proyectos ICT.
   
   
   
   • Percepción de que se está presente en todas las fases del proyecto (muchas veces se da sólo soporte o se entra a medio proyecto).
     
   • Percepción de que el trabajo que uno completa no es necesario mantenerlo, ni nadie va a tener que leerlo, por lo que no tendrá que hacer mucho esfuerzo en ello (recomiendo leer Romario vs Makelele)
     
   • Percepción de que no se tendrá que utilizar el código de otros.
     
   
   
2. Falsa imagen del informático transmitida en los medios. Y además negativa. Porque si fuera tipo Urgencias o Scrubs con los médicos o CSI con los criminalistas probablemente se apuntarían muchos más. Pero las películas presentan a los informáticos como gente generalmente asocial, raros, empollones, rebeldes o "piratas" que no se relacionan con otros y que tienden a dedicarse todo el tiempo a sentarse en frente del ordenador. Esto atrae a gente con ese perfil.
   

Y continuaba diciendo, ¿qué es lo que las empresas buscan? Gente sociable, que sepa trabajar en equipo, que contribuyan y sepan escuchar y que no se salten las normas continuamente.

La verdad es que hay cosas en las que no coincido, pero me parecieron reflexiones interesantes.

¿Es cierto que el perfil de los informáticos y telecos que conocéis es el que presentan las películas? ¿Tiene la culpa el cine de la imagen de los informáticos? ¿Hay una diferencia real entre las cualidades de los estudiantes de informática y telecomunicaciones que salen de nuestras universidades y lo que esperan las empresas?

Sopa de Siglas

Preguntándome sobre las diferentes descripciones del puesto de CIO (lo traduciré como Director de Sistemas y Tecnologías de la Información, para intentar seguir un poco los consejos de Pedro respecto al uso del castellano) dependiendo de la empresa en la que se trabaje, rápidamente me encontré buscando en Google una imagen que representara responsabilidades (gestion de personas, proyectos, proveedores, definición de estrategia ...) y tecnologías/procedimientos.

Respecto a esto último, las tecnologías y procedimientos, una vez se pasa una primera clasificación más general, enseguida empiezan a aparecer siglas y más siglas: ERP, CRM, SRM, BI, CMI, BSC, EIS, DSS, SEO, SEM, PPM (PLM), SSO, A4C (AAA), ECM (CMS), SOA, BPM, EAI, ESB, B2B, B2C, DBMS, ASP, VoIP, QoS, KPI, ITIL, PMI ...

Y eso sin entrar en "frameworks" (lo siento, no me gustan las traducciones de esta palabra) de programación o protocolos porque si no: J2EE, JSF, PHP, SIP, SOAP, REST, LDAP, XML, WML, VXML, XSL, SQL, EAP, SMS, MMS, RADIUS, VPN, TCP ...

Lo peor es cuando te encuentras con siglas que significan varias cosas, como ASP. Me acuerdo a una persona de Telefónica hablando a un antiguo compañero mío sobre las posibilidades de utilizar un producto en un entorno ASP (Application Service Provider) y él, programador como era, pensando en qué tenía que ver ASP (Active Server Pages) en todo esto si el producto estaba programado en Java.

¿Habrá una profesión en la que se usen más siglas que en la nuestra? ¿Te has sentido alguna vez perdido en una conversación con temor a preguntar algo? ¿Tienes alguna anécdota relacionada con siglas?

Business Case I: Razones, Opciones, Beneficios

El otro día me sorprendía (en realidad no) al hablar con un compañero de carrera y observar la cantidad de proyectos que se desarrollan sin un Business Case en algunas empresas.
Algunos se preguntarán, ¿por qué es tan importante tener esta información? Voy a intentar dar algunas pistas al respecto.

Lo primero que hay que entender es que el Business Case es un instrumento vivo que evoluciona a lo largo del proyecto y que se ve afectado por circunstancias internas o extenas al mismo. Debido a su contenido, debería ser el punto fundamental que haga decidir en cada etapa del proyecto si es conveniente seguir con él o si es necesario abortarlo.


Para entender mejor estas afirmaciones voy a comentar parte de su contenido brevemente en esta entrada, para completarlo en otras entradas posteriores.

El primer elemento que no debe faltar dentro del BC es el conjunto de razones que llevan a realizar el proyecto. Por ejemplo, la necesidad de gestionar mejor a los clientes debido a un conjunto de quejas en aumento o a una previsión en el aumento del número de estos. Estas razones ofrecen una base para entender por qué se sugirió el proyecto en un principio.

En segundo lugar se encuentran las opciones. ¿Qué acciones podemos tomar para atender a esa razón, problema o deseo inicial? Prince2 sugiere que siempre se considere la opción de "No hacer nada" y utilizarla como la base con que comparar el resto de opciones. En el ejemplo, ¿qué pasaría si no hiciéramos nada? ¿Se resentiría la atención a los clientes? ¿Perderíamos clientes? Frente a esta opción se plantearán todas las que se hayan considerado, indicando la elegida y el porqué de la selección. En nuestro caso podríamos plantear hacer "reingeniería de procesos", instalar un CRM comercial mediante consultoría externa, desarrollar nuestra propia solución software o una combinación de éstos.

Otro aspecto fundamental es la definición del conjunto de beneficios que se esperan del proyecto. Estos beneficios han de ser expresados en términos medibles (cuánto y cuándo) estableciendo la situación actual para poder realizar la comparación cuando finalice el plazo establecido. En el proyecto que estamos comentando algunos beneficios (no necesariamente compatibles) podrían ser "mantener el 95% de los clientes actuales (frente a un 20% estimado de pérdida si no se hace nada) durante los próximos dos años", "reducir un 30% el número de quejas a finales de año con respecto a las actuales", "incrementar los clientes totales en 10.000 manteniendo el número de reclamaciones en el porcentaje actual". Estos valores medibles o procentajes pueden incluir un margen de variación o tolerancia en el beneficio.

Los riesgos que afronta el proyecto y que pueden afectar al BC se pueden incluir también en el mismo, dejando los detalles de su resolución a otros documentos del proyecto.

Evidentemente, los elementos económicos serán fundamentales dentro del BC y, por tanto, los trataré en otra entrada.

¿Realizas un BC de todos tus proyectos?

Marca 2.0

Llego a través de una entrada del blog de navegapolis.net a un libro electrónico que explica de una forma muy metafórica cómo establecer relaciones con tus clientes. El libro se llama 21 Posturas para hacer el amor con tus clientes. Guía para entender el branding en un mundo 2.0.

Y tú, ¿qué postura practicas más?

Más innovación corporativa

El otro día hablaba sobre la innovación corporativa mediante la generación de concursos o comunidades (algunos lo incluyen en el crowdsourcing). En relación a este tema, Businessweek publicaba en este artículo información sobre los premios de Innovación de Cisco con un total de 250000 dólares al equipo ganador y la oportunidad de crear una unidad de negocio. Es interesante leer las precauciones legales y de recursos humanos que se tienen que salvar en este tipo de acciones.

Yo me quedo con esta frase del artículo: We got more ideas in two months from this mechanism than our internal site did in about a year and a half.

¿Creéis que empresas tecnológicas como Telefónica o Gamesa y otro tipo de empresas más tradicionales como bancos o constructoras se beneficiarían de este tipo de medidas? Lo más cercano que he visto en Telefónica es el intento de crear una comunidad open source (Morfeo) cuyo éxito o difusión no tengo muy claro o la iniciativa Tú marcas tendencias, de las que no he visto una gran promoción ni llego a ver qué tipo de gente intentan involucrar.

Combinando metodologías

Existen numerosos artículos en la red sobre cómo combinar metodologías de gestión de proyecto tradicionales más centradas en el control tipo Prince2 con metodos Agile. Hoy he encontrado un libro que habla sobre cómo trabajar con Prince2 y DSDM. DSDM es una metodología creada en Gran Bretaña a finales del siglo XX.

Lo cierto es que soy bastante escéptico en relación a este tipo de libros. ¿Habéis leído alguno de este estilo que creáis interesante recomendar? ¿Combináis técnicas de gestión tradicional con métodos Agile en vuestros proyectos?

Arquitectura empresarial y Zachman

John Zachman desarrolló un marco de trabajo para la arquitectura empresarial llamado Zachman framework que ha sabido explotar creando su propia empresa de consultoría - ZIFA.

Zachman framework se resume de forma clara en este PDF que se puede descargar de la web de ZIFA. Básicamente, se utiliza una representación bidimensional. En un lado se presentan las diferentes perspectivas del problema vistas por distintos actores que participan en la definición de la arquitectura empresarial:

• El planificador. Perspectiva contextual observando el ámbito de la empresa.
• El propietario. Perspectiva conceptual que se presenta en el modelo de negocio.
• El diseñador. Vista lógica ofrecida en el modelo del sistema.
• El constructor. Modelo tecnológico incorporando la vista física.
• El implementador. Con la representación detallada.
• El trabajador. Representa el funcionamiento de la empresa.

En el otro eje se representan el Qué (Datos), Cómo (Funciones), Dónde (Localizaciones y Red), Quién (Gente), Cuándo (Tiempo) y Por Qué (Motivación).

Esta visualización en forma de cuadro permite alinear la visión del propietario con el resto de visiones, modelos y acciones que se llevarán a cabo para construir la arquitectura de la empresa. No es necesario desarrollar todos los modelos o rellenar todas las celdas, dependerá de los objetivos buscados en cada caso.

Aparte de la sincronización de modelos, otra de las ventajas es poder localizar qué información es necesario presentar a cada actor dentro de la empresa y en qué formato.

Underachievers

Sí, lo sé, lo siento, pero no he podido evitar escribir una entrada sobre la selección española de fútbol. Aunque tenga que ver con la gestión de equipos.

Aquí en Reino Unido, cada vez que hablaban de la selección española comentaban que quizá éste era su momento y que eran una panda de "underachievers" (con menor rendimiento del que se espera de ellos) crónicos. Con la coletilla de que quizá podrían hacer algo ahora que algunos de sus jugadores participan en la Premier League.

La cuestión es que, analizando las razones por las que la selección de España ha podido ganar la Eurocopa, aparte de la posibilidad esgrimida por algunos comentaristas ingleses se podrían encontrar las siguientes (¿cuál crees que es la que más ha influido?):

- Una buena gestión de de las personas realizada por el Line Manager Luis Aragonés.
- Una buena selección del equipo buscando que las personas fueran las adecuadas para las labores a realizar y colocándolas en los lugares correctos.
- Un equipo entusiasmado por un proyecto y que se cree capaz de conseguirlo.
- Un buen ambiente de trabajo sin personas que provocaran enfrentamientos internos.
- Un jefe de proyecto que lleva adelante el proyecto y no se deja influir por terceros ajenos al mismo.
- Sugiere otros...

En los proyectos que hayáis gestionado con éxito, ¿qué razón principal creéis que fue la que más ayudó al resultado final? ¿Cómo generáis entusiasmo en los proyectos?

Otras tolerancias en el proyecto

En entradas previas hablaba de las tolerancias estándar de los proyectos y del Risk appetite. Aparte de estas tolerancias existen otras tres definidas en Prince2 que es importante comentar:

• Tolerancia en el ámbito del proyecto. Consiste en dividir los requisitos (que no requerimiento) de un proyecto en "esenciales" y "deseables". Cuando no es posible producir el proyecto dentro de los límites de tiempo y coste establecidos, esta es una opción posible. Como me dijeron mis caseros actuales: "La casa estará disponible a partir del día que comentas, pero no podremos quitarte la moqueta del baño antes de esa fecha".
• Tolerancia en los beneficios. Los beneficios definidos en el Business Case pueden incluir una determinada tolerancia siempre y cuando sigan justificando la inversión en el proyecto. Un ejemplo sería definir que el proyecto proporcionará un incremento de compras en el sitio web del 20% (+/-5%).
• Finalmente, la tolerancia en términos de calidad se produce cuando se está generando un producto dentro del proyecto y se detecta que no cumple todos los requisitos definidos en la descripción del producto. Si el tiempo para corregir ese error puede hacer peligrar la consecución del proyecto, la Junta de Proyecto puede aceptar dicha disfuncionalidad mediante una concesión.

Todas estas tolerancias sirven como controles dentro del proyecto.

The Apprentice: Ganador

En el último capítulo de The Apprentice, los participantes, divididos en dos grupos de dos personas, tenían que crear una nueva fragancia cuyo coste estuviera en torno a las 20 libras. Para ello contarían con la ayuda de los concursantes ya expulsados de la serie. En una presentación ante gente experta tendrían que exponer las cualidades de su producto.

Uno de los equipos diseñó un frasco muy innovador con un aroma novedoso. Su presentación fue buena y los expertos les felicitaron por haber conseguido un producto tan bueno en sólo dos días. Lamentablemente un aspecto se les escapó de las manos, el coste. Para producirlo requerían 3 o 4 veces el coste definido. Y este fue su máximo error. Por destacar en el producto olvidaron ver "el bosque".

El equipo ganador generó un producto mediocre, pero dentro de los parámetros establecidos.

Finalmente, la persona contratada fue el participante que más había destacado por sus resultados a lo largo de las semanas del programa. Curiosamente, la persona que mintió en su CV pues se sentía avergonzado de su falta de educación universitaria frente a los demás concursantes. Esto se vio compensado por su capacidad de entrega y de producir lo esperado.

¿Blog como herramienta de venta?

Comentando el otro día con un conocido el uso de los blogs como herramienta de marketing empresarial, nos preguntábamos si era posible utilizarlo como punto de venta de proyectos a clientes cuando el canal comercial de acceso a éstos es muy cerrado.

Al estilo de la gente que publica mashups de Google u otras aplicaciones desarrolladas por ellos, la idea sería que se publicaran enlaces a prototipos de desarrollos de una aplicación (junto con la explicación del mismo) para un sector concreto sin identificar un cliente específico.

En realidad, no difiere mucho de la actual información sobre productos que se da por parte de las empresas, solo que en este caso no sería un producto sino el prototipo de una posible aplicación a desarrollar en un proyecto.

Evidentemente, si nadie visita tu blog y no impones algún tipo de posicionamiento para que la gente lo encuentre, este canal comercial no serviría de mucho.

¿Publicarías prototipos de tus proyectos en tu blog? ¿Temes que la idea te la pudieran robar? ¿Consideras que no es un buen canal comercial y que es mejor ir directamente a los clientes?

Vídeos de formación gratuitos

Encuentro este sitio web con enlaces a numerosos vídeos de formación gratuitos.

Los vídeos están clasificados en diferentes categorías entre las que encontramos "Business and Management" y "Computer Science".

Muy recomendable para seguir con la formación remota.

Pausa vacacional

Esta semana estoy de vacaciones, prometo recuperar la que viene.

Mientras tanto, he aprovechado la capacidad de programar entradas y he dejado un par de píldoras preparadas para esta semana.

Nos leemos.

Incrementar la innovación corporativa

De vuelta de Madrid tras asistir a los premios COIT a las mejores tesis doctorales y premios fin de carrera, en los cuáles diversas empresas patrocinaban la entrega de los mismos según el tema del premio, he decidido escribir este post que me venía rondando un tiempo por la cabeza.

Uno de los aspectos que creo poco explotado por las empresas es la posibilidad de incrementar su capacidad de innovación mediante la generación de comunidades. ¿Qué quiere decir esto? Implicar a terceros, a personas ajenas a la empresa, en la generación de nuevas ideas, nuevas aplicaciones y servicios.

Pongamos un ejemplo. Imaginemos que un banco cualquiera, llámese Caja Cajera decide copiar el modelo de Google y proponer un concurso (premio incluido) en el que cualquier persona o grupo de personas puedan desarrollar una idea/aplicación innovadora para banca. Crea además una comunidad (foro, información técnica) en la que la gente se pueda dar de alta y personas con ideas puedan contactar con gente con habilidad para desarrollarlas. Pongamos que la Caja Cajera promociona este concurso en sus oficinas, en los medios y en las universidades (donde existe un gran caldo de cultivo) y decide dar un conjunto de premios que incluyen comprar los proyectos ganadores, financiar empresas creadas por las personas que den las mejores ideas o contratarlas ...

¿Qué beneficios obtiene una empresa con este tipo de acciones? 1) Incrementar su capacidad de innovación, 2) localizar personas con aptitudes, 3) habilitar nuevos canales para recibir ideas, entre otros.

A costa todo ello de una carga de gestión adicional que, sinceramente, creo que está más que justificada.

Algunas empresas han iniciado este tipo de camino, pero o se han equivocado de enfoque o no han puesto un esfuerzo detrás lo suficientemente importante para dar a conocer la iniciativa.

A este tipo de acciones que involucran a terceros independientes de forma más o menos indiscriminada es lo que yo llamo Innovación Corporativa por Comunidades.

Entrevistas en The Apprentice

Ya llega la recta final de este programa y en el pasado programa se sometió a los concursantes a unas entrevistas en las que trataba de valorar aspectos como sus aptitudes, su fuerza de carácter o su interés por trabajar en la empresa. Me parecieron situaciones curiosas en las entrevistas:

- La técnica de "véndeme este boli". Comprobar la capacidad del entrevistado para venderte el primer objeto que se te venga a la mente.
- La capacidad para mentir en el CV. Uno de los concursantes puso que había estado 2 años en la universidad, cuando sólo había pasado 4 meses. Una comprobación con la Universidad descubrió el pastel.
- Las faltas de ortografía en el CV. Y no digo erratas, digo faltas de ortografía continuas. ¿Para qué sirve el corrector ortográfico?
- La técnica del tu-cv-es-basura o eres-completamente-inempleable. Seguramente sólo para aquellos trabajos en los que te ofrezcan un número de 6 cifras en libras.
- Los comentarios en los que se sugería que una entrevista es en realidad una conversación y que cuanto antes enganches a la otra persona mucho mejor.

Cuidando a los clientes

La gestión de la relación con los clientes es un aspecto muy importante dentro de la empresa. No obstante, la palabra gestión en este ámbito tiene para mí una componente demasiado neutral y preferiría hablar de "el cuidado", "la asistencia" o "la conservación". Estos vocablos ayudan a establecer en nuestro subsconsciente una idea más clara de lo que las empresas deberían hacer con este tipo de relaciones.

Todo esto viene al caso porque la empresa que me arrienda la casa aquí en Reino Unido me ha hecho darme cuenta de la capacidad para la incompetencia que puede llegar a darse. Dejando a un lado muchos otros temas que he conseguido que solucionen tras lidiar durante meses con ellos, siguen mandándome las facturas con errores. Así que esta vez, cambiando de estrategia, he decidido aplicar un poco de humor y mandarles en un correo un enlace que me ha parecido relacionado. ¿Se darán por aludidos?

Más formación en vídeo

Navegando por baquía encuentro una sección de formación en vídeo en la que hablan de gestión avanzada de clientes, plan de negocios y Google Adwords.

Aunque la idea es buena y los contenidos parecen interesantes, tengo la impresión de que el formato vídeo se podría haber utilizado de una forma más dinámica (como mostrando casos de ejemplo). No he visto todos los vídeos, por lo que puede que en alguno de ellos haga uso de técnicas más novedosas. Me da mejor impresión cuando hay un diálogo que en la presentación individual.

Ya hemos hablado en este mismo blog sobre el opencourseware.

¿Conocéis webs con vídeos de formación recomendables? ¿Es más común encontrar este tipo de material para temas técnicos (vídeos de Google, presentación de open id ...) que para otro tipo de materias?

Lecciones aprendidas

Un documento típico que se ha de producir al finalizar un proyecto es el Informe de Lecciones Aprendidas. Digo "se ha de producir" porque lo he visto generado muy pocas veces. Desde un punto de vista de organización, contar con datos acerca de cómo mejorar aspectos de la gestión y compartirlos es básico para poder proporcionar una mejor calidad a los clientes o a la organización.

Este tipo de documentos no se genera de un día para otro y, por eso, conviene llevar un registro de los puntos que se han ido detectando a lo largo del proyecto y que podrán ayudar en posteriores fases del mismo o en otros. Algunos ejemplos de contenido son: fallos en la planificación y cómo evitarlos (métodos, herramientas, valoraciones ...), mejoras necesarias en el control de calidad de los productos o en estándares utilizados por la organización, consideraciones positivas o negativas en la relación con los proveedores, incidencias en la implicación del negocio, los usuarios o los proveedores, herramientas o tecnologías que no funcionaron como se esperaba (mejor o peor).

Estos documentos, una vez almacenados y distribuidos a los interesados podrán ser utilizados para tomar decisiones que faciliten un mejor resultado en proyectos posteriores o proyectos en curso que utilicen similares técnicas, métodos, herramientas o actores.

¿Sentido común?

Complementariedad intergeneracional y bloaching

El otro día hablaba con un amigo del talento desperdiciado en los directivos que se jubilan o prejubilan o, simplemente, las empresas prescinden de ellos, y cómo podían aportar su experiencia y su red de contactos para complementar a gente más joven aunque sobradamente preparada.

Así, llegamos a la conclusión de que nos gustaría que existiera una web tipo meetic.com o match.com, pero orientada a poner en contacto personas de gran potencial y carrera ascendente con personas de gran experiencia y proyección que facilitara la creación de proyectos conjuntos, relaciones de coaching y demás.
Incluso podían dar lugar a triángulos con inversores dispuestos a poner dinero en esos proyectos.

Por otro lado, últimamente estoy viendo varios blogs en los que la gente expone sus situaciones profesionales y busca respaldo o sugerencias. Esto me ha dado que pensar si se está empezando a dar (o se lleva tiempo dando) una especie de coaching a través de blogs que podríamos llamar "bloaching" (ahí va un palabro que morirá en pocos días salvo que alguien haga marketing viral).

Proyectos fallidos

Leo en CIOInsight un artículo acerca de la experiencia de una persona en la resolución de proyectos con riesgo de fracaso y en el que aporta algunas sugerencias sobre qué camino seguir y cuál no (explicando un proyecto que no pudieron rescatar). Seguro que más de uno se siente identificado como bombero o paracaidista de proyectos, que es justo lo contrario de lo que pretende defender el autor. Algunas pistas incluyen seguir contando con el equipo de proyecto existente en la medida de lo posible, evitar hacer al equipo realizar un esfuerzo extra buscando formas de trabajar más inteligentes y productivas o elegir las batallas que se pueden ganar o los proyectos cuya solución se puede abordar.

También en CIO Insight se muestra una presentación con los resultados de una encuesta hecha entre CIOs acerca de las razones que llevaron a cancelar proyectos IT.



En ella se definen como las principales causas de cierre de proyectos 1) el cambio de necesidades de negocio, 2) la incapacidad del proyecto de cumplir las expectativas prometidas, 3) cambio en las prioridades, 4) sobrepasar el presupuesto y 5) que el proyecto no estaba alineado con el negocio. Además propone algunas acciones que podrían adoptar los CIOs para corregir algunos de estos aspectos.

Finalmente, y relacionado también con los fallos. Algo importante es siempre aprender de los mismos. Un artículo de businessweek trata este tema indicando lo importante que es ser perseverante y poniendo algunos ejemplos de ilustres que han cometido errores y se han sabido sobreponer a los mismos.

¿Tienes complejo de bombero? ¿Has aprendido de algún error últimamente?

Pequeñas decisiones en las PYMEs

El otro día quería comprar pan y la panadería-pastelería de mi barrio lleva cerrada desde Febrero. Aquí en Reino Unido, al menos en las pequeñas ciudades, no es tan sencillo comprar pan de barra como en España y hay que encontrar una panadería o irse a algun supermercado tipo ASDA o Tesco.

La cuestión es que no quería coger el coche y la panadería más cercana (de la misma cadena que el despacho de pan cerrado) se encuentra a unos 20 minutos andando. Cuando pasé por delante de la puerta de la tienda cerrada descubrí un cartel que decía que una furgoneta de esa compañía paraba por la zona sin indicar el lugar exacto. "Estate atento" decía. Me dije para mí, ¡seguro que la información está en su página web! Pues, ¿adivináis? Casi. Sí tenían página web, pero de esa información ni rastro.

Esto viene al caso porque, en un país como este en el que la gente no suele comer en restaurante y las furgonetas de pan, sandwiches y pasteles van a las zonas industriales/tecnológicas, algo tan sencillo como publicar las horas y rutas de las mismas en la web o, más aún, dar la posibilidad de solicitar que te lleven un producto concreto en dicha ruta no lo he visto implementado en ninguna PYME. Pequeñas decisiones que no cuesta mucho implementar y que podrían proporcionar un ingreso adicional. En España algunos restaurantes te mandan el menú del día por correo electrónico si te suscribes.

Otro ejemplo, según un reportaje que leí el otro día en El País un evento en Llanes trata de atraer artesanos a las nuevas tecnologías como canal de venta.

¿Conocéis algún caso de alguna PYME en la que compréis que pudiera tomar alguna decisión para obtener un mayor beneficio o dar un mejor servicio?

Mujeres en la Dirección

Interesante la propuesta de la Harvard Business School que leo en businessweek.com sobre la necesidad de las empresas de mantener y retener el talento localizado en mujeres en torno a 40 años. La justificación es que el ciclo de vida de las mismas es diferente al de los hombres dando lugar a trabajadoras muy capacitadas para los puestos C (CEO/CIOs/COO...) en posteriores estadios de su desarrollo profesional si se consigue mantener su relación con la empresa. Esto facilita la gestión de la sucesión incrementando el banquillo de personal y talento disponible. Indirectamente reduce la cantidad de dinero necesaria para pagar a los directivos pues muchas veces se desembolsan enormes cantidades para a atraer a gente de fuera, cuando puede ser más rentable promocionar a alguien de dentro.

Otro artículo relacionado sobre este reto para las mujeres y las empresas.

The Apprentice: Pañuelos y Coches de Lujo

Voy a aprovechar para tratar los dos últimos retos propuestos a los participantes de The Apprentice en temas de gestión.

La semana pasada, de nuevo se le presentó un reto de marketing y branding ("promoción") para los dos equipos. En esta ocasión se les proponía crear una nueva marca de pañuelos de papel ("tissue"), definir la imagen de la marca con la caja donde se venderían, producir un anuncio publicitario para la televisión y otro para una revista. La evaluación del resultado la harían un conjunto de expertos en este tipo de temas pertenecientes a una compañía de "advertising" a los que se les haría una presentación.

Los principales errores de los que aprender fueron:
- Falta de creatividad para buscar el nombre de la marca para los perdedores ("I love my tissues") frente a los ganadores ("Atishu").
- Falta de creatividad a la hora de realizar el anuncio en el equipo ganador.
- Error enorme del equipo perdedor a la hora de hacer el anuncio pues se centraron en la creatividad y se olvidaron de que se tenía que entender qué producto se vendía.
- Mala selección de la persona que presentó el producto a los expertos en el equipo ganador que pareció sumamente inseguro.

El expulsado, el jefe de proyecto y máximo creativo del anuncio que apenas mostraba el producto.

El capítulo de esta semana se centraba en la capacidad de venta de los participantes. Ellos debían elegir 2 coches de lujo de una lista que se les presentaba y alquilarlos por horas o días. En el rango de productos por seleccionar había coches desde 675 libras a casi 3000 libras por día (precio). Además tendrían 2 momentos para conseguir que los alquilaran, el primero por la mañana en el que debían seleccionar dos puntos de la ciudad donde realizar esta actividad (placement) y el segundo por la tarde en una plaza céntrica de la City londinense ya fijada.

Los principales errores de los equipos fueron:
- Mala selección de la localización por parte del jefe de proyecto del equipo perdedor.
- Poca capacidad de venta del equipo perdedor.
- Desconocimiento del mercado de lujo y de la capacidad de personas en el mismo de permitirse alquileres caros como el de 3000 libras llevaron al equipo perdedor a elegir coches de precio intermedio (Ferrari y Spiker) frente al equipo ganador que eligió un Aston Martin de precio intermedio (siempre dentro de coches de lujo, claro) y un Zonda que era el producto más caro y que consiguieron que tres personas alquilaran por un día. Hay que reconocer que en este programa ha salido rentable por ahora asumir riesgos.

Cursos abiertos

Para aquellos que no tienen tiempo suficiente para la formación presencial, en algunas materias se puede recurrir a la formación online. Entre los numerosos cursos que se pueden realizar utilizando plataformas de teleformación se encuentran MBAs o cursos técnicos entre otros.

Una opción alternativa para los autodidactas consiste en acudir a los materiales que publican de forma libre las diferentes universidades. La iniciativa OpenCourseWare del MIT incluye ya más de 1800 cursos, algunos de ellos con audio/vídeo. A quién le interese qué socios españoles se han sumado al consorcio formado tras esta iniciativa puede visitar su sitio web.

Mi duda es, ¿se unirán las escuelas de negocio a este tipo de iniciativas?

Proyecto Phoenix

Viendo en televisión el resumen de la llegada de la misión Phoenix de la NASA a Marte, me sorprendí gratamente cuando escuché que la persona entrevistada era el jefe de proyecto de la misión. Son pocas las ocasiones en las que he visto dar publicidad a un director de proyecto en los medios generalistas por un proyecto completado de forma exitosa.

En relación a este mismo proyecto leo en CIO.com un artículo que comenta las dificultades en relación a la gestión de contenidos dentro del mismo.

Abortar un proyecto de forma ordenada

Existen numerosos aspectos que me parecen muy interesantes en metodologías de gestión de proyecto como Prince2. Uno de ellos es la importancia que se le da a la opción de cerrar el proyecto prematuramente cuando se evalúan distintas alternativas, ya sea en los puntos de decisión y control entre etapas de proyectos o cuando se recibe un informe de excepción.

Cualquiera de nosotros es capaz de acordarse de algún proyecto que se ha continuado sólo porque la inversión realizada hasta el momento era muy grande, sin tener en cuenta si los objetivos del proyecto seguían siendo alcanzables desde un punto de vista de negocio. Existen muchos aspectos que pueden hacer que no sea rentable continuar con un proyecto. Estos aspectos pueden ser internos como desviaciones que incrementen el coste o el tiempo por encima de la tolerancia establecida o implique reducir el ámbito del mismo, pero también pueden ser externos como nueva legislación en el sector o acciones de la competencia.

Por tanto, es necesario tener siempre en cuenta la posibilidad de abortar el proyecto para no incurrir en costes adicionales que no proporcionen el beneficio esperado. Este cierre prematuro de proyecto ha de ser un cierre controlado. En Prince2 implicaría ejecutar el proceso de cierre de proyecto CP, incluyendo la generación de documentos como los informes de Lecciones Aprendidas, de Fin de Proyecto aunque adaptado a un final prematuro o Recomendaciones de acciones futuras a seguir (por ejemplo, posible usos de los resultados del proyecto para otros fines) entre otros. También es necesario generar la notificación de fin de proyecto para liberar los recursos asignados por los distintos actores.

Y tú, ¿tienes en cuenta este aspecto en tus proyectos?

The Apprentice: Venta emocional

En el capítulo de The Apprentice de la semana pasada, los equipos de proyecto se enfrentaban a un reto complejo que consistía en vender vestidos de novia y otro accesorio para la boda en una feria de novias.

Para ello, los equipos recibían una lista de tiendas de vestidos y tiendas de accesorios y debían seleccionar una de cada. En caso de coincidir en un proveedor, éste decidiría qué equipo se haría con sus servicios.

La clave de la victoria se encontraba en seleccionar los productos adecuados y en saber venderlos, algo que no siempre es sencillo, sobre todo si te encuentras con una venta en la que las emociones del comprador influyen en gran medida.

El equipo perdedor cometió los siguientes errores:

• Para seleccionar a los proveedores, la jefa de proyecto repartió al equipo por zonas geográficas en vez de por productos, con lo que era muy difícil comparar unos con otros. Esto llevó a que la jefa de proyecto seleccionara los vestidos de precio medio que se diferenciaban en ser de colores variados, en vez de arriesgarse con el diseñador de moda más conocido cuyos vestidos eran mucho más caros con toques de película medieval, pero tenían un mayor margen.
  
• La forma de vender agresiva de dos de sus miembros en relación a los accesorios (tartas y pasteles de boda) llevó a varias personas a no comprar.
  
• Debían haber escogido un producto accesorio distinto ya que la feria era para novias y los pasteles son un producto que se suele comprar por la pareja. Es necesario aclarar que su primera selección de accesorios no eran los pasteles, sino lencería y sandalias, pero coincidieron con el otro equipo y el proveedor se decidió por los otros debido a los vestidos que le acompañaban en el expositor. De cualquier modo, su segunda opción debía haber estado más estudiada.
  

El equipo vencedor decidió optar por los vestidos caros y resultó ser una apuesta con éxito al vender 3 de ellos. Eso sí, sufrieron hasta el último momento ya que las novias se lo habían probado al inicio de la feria, pero el precio había hecho que esperaran al último momento tras visitar el resto de expositores. Asumieron un riesgo grande y obtuvieron buenos resultados gracias al nombre del diseñador.

Secretos para destacar en IT

Encuentro un artículo en CIO.com que sugiere cuatro actitudes que se han de seguir si se quiere ser una estrella dentro del mundo IT. En resumen:

• Tratar bien a los usuarios finales. Evitar hacerles sentir estúpidos, evitar la jerga técnica y ser capaz de traducir entre lo que te dicen y la información que necesitas. Aprovechar cada oportunidad para establecer relaciones con los usuarios y que te conozcan.
  
• Entender el negocio para poder proporcionar las mejores soluciones. Ir departamento a departamento conociendo a la gente y establecer reuniones con los distintos equipos para entender su negocio. Esto permite ser proactivo ofreciendo soluciones que el usuario no hubiera pensado.
  
• Entender los objetivos y estructura de la organización. Y así poder priorizar y seleccionar los proyectos relacionados dando un paso adelante cuando sea necesario para obtener visibilidad.
  
• Establecer una relación de confianza con tu jefe. No ocultar la información negativa ni saltarse el escalafón. Seleccionar o definir junto a él los momentos adecuados para proporcionar dicha información.
  

Son consejos interesantes y hasta evidentes. Aunque siempre existen situaciones concretas en las que es más difícil aplicarlos, conviene mantenerlos siempre en la cabeza.

Innovación: Premios COIT/AEIT

Hoy he recibido un correo del COIT/AEIT con el resultado de la XXVIII Convocatoria de Premios “Ingenieros de telecomunicación” a las mejores Tesis Doctorales y Proyectos Fin de Carrera.

Respecto a las Tesis doctorales, siempre es importante echar un vistazo a qué tipo de trabajos se están realizando en la universidad.

Enhorabuena a los premiados ;-)
Aquí van los ganadores:

• Premio ALCATEL-LUCENT a la Mejor Tesis Doctoral en Nuevos Servicios Interativos sobre IPTV.
  Autor: Sr. D. Matías Toril Genovés
  Tesis: " Self-Tuning Algorithms for the Assignment of Packet Control Units and Handover Parameters in GERAN. "
  
  
• Premio BANESTO a la Mejor Tesis Doctoral en Tecnologías de la Información y las Comunicaciones en la Banca.
  Autor: Sr. D. José Luis Ruiz Revuelta
  Tesis: " A Policy-Driven, Model-Based Software and Services Deployment Architecture for Heterogeneous Environments. "
  
  
• Premio COIT/AEIT a la Mejor Tesis Doctoral en Gestión, Economía y Regulación de las Telecomunicaciones.
  Autor: Sr. D. Alfonso A. Sánchez-Macián Pérez
  Tesis: " Contribución a la Medida de Calidad de Servicio Percibida en Servicios Telemáticos Mediante la Definición y Representación de Relaciones Formales entre Ámbitos de Calidad. "
  
  
• Premio COIT/AEIT a la Mejor Tesis Doctoral en Fundamentos y Tecnologías Básicas de la Información y las Comunicaciones, y sus Aplicaciones.
  Autor: Sr. D. Josep Manuel Martínez Canet
  Tesis: " Photonic Logic Gates: Boosting all-Optical Header Processing in Future Packet-Switched Networks. "
  
  
• Premio ERICSSON a la Mejor Tesis Doctoral en Aplicaciones para Entornos Multimedia.
  Autor: Sr. D. Ignacio Martínez Ruiz
  Tesis: " Contribuciones a Modelos de Tráfico y Control de QoS en los Nuevos Servicios Sanitarios Basados en Telemedicina. "
  
  
• Premio Fundación ORANGE a la Mejor Tesis Doctoral en Nuevas Tecnologías para la Discapacidad.
  Autor: Sr. D. César Cáceres Taladriz
  Tesis: " Nuevos Procedimientos Telemédicos para el Seguimiento y Cuidado de Pacientes VIH en Estado Crónico. "
  
  
• Premio Fundación TELEFÓNICA a la Mejor Tesis Doctoral en Redes y Servicios de Telecomunicación.
  Autora: Sra. Dña. María Canales Compés
  Tesis: " Provisión de Calidad de Servicio en Redes Móviles Ad Hoc Basada en el Diseño Cross-Layer de Algoritmos de Encaminamiento. "
  
  
• Premio Fundación VODAFONE a la Mejor Tesis Doctoral en Comunicaciones Móviles Avanzadas y Nuevos Servicios en Movilidad que contribuyan a la Igualdad de Oportunidades para Todos.
  Autora: Sra. Dña. Raquel Barco Moreno
  Tesis: " Bayesian Modelling of Fault Diagnosis in Mobile Communication Networks. "
  
  
• Premio ISDEFE a la Mejor Tesis Doctoral en Seguridad y Defensa.
  Autor: Sr. D. Carlos Rivera de Lucas
  Tesis: " Estudio de Estructuras de Baja Dimensionalidad y Avanzadas para la Detección de Radiación Visible y Ultravioleta Basadas en Nitruros del Grupo III. "
  
  
• Premio LA CAIXA a la Mejor Tesis Doctoral en Comercio Electrónico.
  Autor: Sr. D. Gabriel Maciá Fernández
  Tesis: " Ataques de Denegación de Servicio a Baja Tasa contra Servidores. "
  
  
• Premio ONO a la Mejor Tesis Doctoral en Televisión Interactiva como Agente de Integración Social.
  Autora: Sra. Dña. Davinia Hernández Leo
  Tesis: " Un Proceso de Diseño Basado en Patrones para la Creación de Macro-Guiones de CSCL (Computer-Supported Collaborative Learning) Representados Computacionalmente con IMS LD (IMS Learning Design) "
  

The Apprentice: Gimkana en Marrakesh

En el capítulo de The Apprentice del viernes pasado los dos equipos, liderados por sus jefes de proyecto, viajaron a Marrakesh con el objeto de comprar todos los artículos de una lista, con la condición de no aceptar el precio inicial que se les ofreciera y así valorar su capacidad de negociación. El equipo ganador sería aquel que hubiera pagado un menor precio por los productos.
Existía una penalización por cada producto no obtenido y por cada producto erróneo (por ejemplo distinto color).

El equipo vencedor consiguió reunir todos los productos a tiempo, aunque eso sí por los pelos ya que para el último producto llegaron al mercado cuando se cerraban las tiendas y tuvieron que correr la voz entre los vecinos de la zona para que les proporcionaran uno.

Al equipo perdedor se le veía acercarse al abismo desde el principio ya que se dirigieron directamente al primer mercado sin ni siquiera pararse a pensar qué productos había que comprar, qué era cada producto y en qué mercados se podían conseguir. Esto les llevó a confundir tres productos (en uno de ellos ni se fijaron en el color que necesitaban) y a vagar de forma desordernada por las diferentes tiendas. Lo peor fue los intentos que realizaron dos de los miembros del equipo por obstaculizar al equipo contrario tratando de sobornar a un vendedor para que no les preparara un producto a tiempo.

En definitiva, una falta de planificación absoluta y desconocimiento del entorno, combinada con una mala capacidad de negociación que les llevó a gastarse más dinero que el equipo contrario sin incluir las penalizaciones. El resultado, dos participantes despedidos: la jefa de proyecto y una de las personas que intentó sobornar al vendedor.

Me pregunto si tendría éxito un programa así en España, en el que participara una escuela de negocio dando como premio un MBA y explicando los errores de los participantes.

¿Enterprise 2.0?

Leo en IDG una noticia acerca de la confusión que produce el concepto de Enterprise 2.0 en el mercado. Hace referencia a otro artículo explicando dicho concepto.

Desde mi punto de vista, la dificultad de identificar el ROI por parte de los CIOs a la hora de plantear la introducción de este tipo de enfoques en una empresa, parte del uso de etiquetas de marketing y de englobar muchas cosas dentro de un mismo concepto.

Si se deja a un lado el concepto abstracto de Enterprise 2.0 y se centra uno en las posibles aplicaciones y herramientas del mismo, es más sencillo discriminar qué elementos son interesantes para la organización y cuáles no.

Al fin y al cabo, el concepto Web 2.0 nació como una agrupación de funcionalidad, capacidades y herramientas que ya existían, pero que se veían como una evolución de la web inicial debido a que se centraban en el usuario y en unas interfaces más visuales. Estos elementos incluyen blogs, wikis, etiquetas y clasificaciones de usuario (folksonomies), compartición de información, fotos y vídeos, sindicación y agregación de información ...

Resumiendo, divide y vencerás.

Gestión de Riesgos: Contramedidas

En una entrada previa hablaba de la tolerancia de riesgos o Risk Appetite. Hoy voy a comentar los tipos de respuestas que se pueden tomar ante la identificación de un riesgo.

En Prince2 se definen cinco categorías en las que se pueden clasificar las posibles contramedidas para afrontar un riesgo. Estas cinco categorías son:

• Prevención: Adoptar mecanismos que eliminen dicho riesgo, ya sea eliminando la amenaza o el impacto de la misma.
  
• Reducción: Emprender medidas que reduzcan la posibilidad de ocurrencia de un riesgo o el efecto del mismo.
  
• Transferencia: Pasar la gestión del riesgo a un tercero. Ejemplos serían una póliza de seguros o una cláusula de penalización en un contrato.
  
• Aceptación: Ya sea porque el riesgo sea muy improbable o porque el coste de las posibles contramedidas sea demasiado elevado en comparación con el posible impacto. En casos extremos el proyecto debería ser reevaluado.
  
• Contingencia: Tener planificadas acciones que se llevarán a cabo si el riesgo finalmente se materializa.
  

Dentro de cada categoría, para cada riesgo puede haber ninguna, una o varias acciones posibles.
A la hora de decidir entre unas contramedidas y otras (o aplicar varias de forma simultánea), es necesario atender a un criterio de proporcionalidad entre posibilidad-impacto del riesgo y coste-tiempo de llevar a cabo las respuestas. Cada acción ha de ser evaluada en función de cómo afecta a los planes de proyecto y el Business Case entre otros aspectos.

Un aspecto interesante a tener en cuenta es que, mientras que las respuestas correspondientes a Prevención, Reducción y Transferencia se pagan mediante el presupuesto del proyecto (pues se planifican como tareas o costes del mismo que se comprometen) las relacionadas con Contingencia se gestionan con un presupuesto específico que recibe ese mismo nombre Presupuesto de Contingencia (Contingency Budget). Este presupuesto está dividido en partidas para cada plan de contingencia definido. En principio (Prince2 es adaptable a cualquier entorno) la aparición de un nuevo riesgo que requiera un plan de contingencia adicional implicará engrosar la cantidad apropiada en el presupuesto de contingencia y, por lo tanto, la aprobación de las autoridades correspondientes.

The Apprentice: Tarjetas de celebración

En el capítulo The Apprentice de la semana pasada, el reto que se le proponía a ambos equipos contaba con una componente muy importante de creatividad. Consistía en seleccionar una celebración y producir una serie de tarjetas de regalo (un sector mucho más extendido en Reino Unido que en España) que había que vender a tres retailers.

El equipo ganador optó por centrarse en el mercado de los "singles" que tanto éxito está teniendo en mucho países y creó tarjetas pensando en venderlas el día antes de San Valentín. Aunque la idea me parece buena, cometieron algunos errores que casi les cuesta la victoria:
1) Dentro del estudio de la industria de las tarjetas, deberían haber deducido que la fecha seleccionada no es la más apropiada puesto que las tiendas destinan un porcentaje muy alto de sus estantes a San Valentín y no tienen espacio adicional. Esto les fue comentado por los dos primeros clientes, que sólo pidieron 1500 tarjetas cada uno. Lo positivo fue la reacción del jefe de proyecto que decidió dejar la fecha variable para la tercera reunión en la que consiguió un pedido considerablemente más grande.
2) A la hora de presentar el producto debían haber preparado una definición del mercado al que iba orientado, esto es, no las personas a las que se les regala la tarjeta, sino las que la compran. Si eres un "single", ¿quién te compra la tarjeta? Tuvieron que improvisar respuestas.
3) Un duda de ortografía en las tarjetas les llevo 2 horas entre que llamaban a bibliotecas, editoriales de periódicos y otros, cada uno dándoles una respuesta distinta. Consejo: busca una frase alternativa y acabarás antes.

El equipo perdedor, además de elegir un tema pésimo, tuvo un jefe de proyecto asombrósamente incompetente. Errores:
1) El tema era algo así como "La semana de la tierra" en la que la gente regalaría tarjetas a otras personas para concienciárles en temas ecológicos, que incluían frases muy pesimistas. No supieron contestar a preguntas de los clientes como "¿por qué alguien compraría una tarjeta tan deprimente?" o "¿por qué gastar papel en un tema ecológico si puedes mandar una tarjeta electrónica?". Quizá preguntar a un grupo reducido de personas en la calle hubiera ayudado a elegir un tema diferente.
2) El jefe de proyecto decidió hacer las presentaciones de venta él mismo cuando tenía a gente en su propio equipo con más experiencia. La falta de tiempo y de planificación le hizo preparar la presentación a última hora.

En resumen una falta de estudio del mercado objetivo y de la industria, una falta clara de planificación y una decisión errónea del jefe de proyecto de no delegar a quién sabe más que tú en esos temas.

Informes semanales CIO insight

El portal web CIO Insight publica un vídeo semanal con información relacionadas con el mundo de los CIOs/CTOs a modo de informe.

En el vídeo del día 16 de Abril incluye tres comentarios interesantes:

1) Cómo Barack Obama incluye en su programa tecnológico el compromiso de crear un CTO nacional. ¿Es esto posible en España en donde existe una gran descentralización debido a las autonomías? Mi visión es que, desde un punto de vista de sistemas de información de la Administración del Estado, sí sería posible y facilitaría la creación de un punto de entrada único para el ciudadano, una especie de "Portal del ciudadano" que facilitaría las gestiones y que derivaría a los sistemas de las autonomías (con su propio CIO) cuando fuera necesario. ¿Una quimera?

2) La responsabilidad del CIO de detenerse un momento a pensar en el negocio de la empresa y cómo alinear IT definiendo una estrategia basada en dicho negocio, sobre todo en momentos de recesión. Esto implica abstraerse de temas más técnicos como virtualización dando un paso hacia conceptos de negocio. Otro artículo/estudio relacionado de CIO Insight analiza si el CIO que existe en la empresa actual es un estratega accidental que aporta más una visión táctica que estratégica.

3) EEUU es el tercer destino más popular para offshore outsourcing (sólo por detrás de China e India) para los CIO británicos. Parece ser que, salvo en temas de soporte, en el resto de los aspectos tecnológicos EEUU está en el top 3. El comentarista sugiere que puede deberse a la sensación de confianza y seguridad que para algunos CIOs británicos ofrece mantener su tecnología en compañías de Reino Unido o EEUU.

Gestión de Riesgos: Risk appetite

A la hora de valorar los riesgos, existen tres parámetros importantes que se han de tener en cuenta: la probabilidad de ocurrencia, su impacto y su proximidad.

La probabilidad de ocurrencia de un riesgo nos permite definir hasta qué punto es factible que dicha incertidumbre se convierta en una realidad. ¿Es igual de probable que un terremoto se produzca en la zona donde se encuentra el centro de datos de la empresa o que se vaya la luz en horas de alto consumo?

El impacto de un riesgo analiza las consecuencias de la ocurrencia de dicho riesgo en todos los aspectos posibles, incluido recursos humanos, materiales y cualquier otro elementos que pueda producir pérdidas de cualquier tipo. En un proyecto se consideraría cómo afecta esta ocurrencia al coste o al tiempo planificado. Para su tratamiento se pueden establecer una escala fija como bajo, medio y alto, asignándoles un valor numérico a cada punto de la escala.

Estos dos elementos son los que se consideran cuando se decide qué tolerancia se va a soportar en relación a los riesgos, es decir, qué niveles de impacto y probabilidad son aceptables y cuáles se han de tratar. Para ello, habitualmente se utiliza una gráfica con dos ejes que representan dichos conceptos, en la cuál se localizan los riesgos. Se traza un límite en dicha gráfica que definirá qué riesgos han de ser tratados y cuáles son aceptables.

Esta tolerancia a los riesgos es lo que se denomina Risk Appetite.

Otros elementos que se utilizan son las gráficas de perfil de riesgos. En dichas gráficas se representa la severidad de un riesgo, que consiste en el producto del impacto por la probabilidad.
El perfil de riesgos consiste en la suma de la severidad de todos los riesgos y representa la severidad acumulada que afronta el proyecto o la unidad organizacional. Este mismo perfil se va recalculando según se definen e implementan contramedidas. Un ejemplo se puede encontrar en esta web.

Finalmente, es importante tener en cuenta la proximidad a la hora de tratar los riesgos. Este parámetro indica en qué momento se puede producir un riesgo, lo que facilita añadir qué riesgos son urgentes, una vez sabemos su importancia.