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?