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.
miércoles, 30 de abril de 2008
martes, 29 de abril de 2008
Tendencias actuales en la gestión estratégica
Encuentro en Blackwell Publishing un vídeo de 20 minutos con una presentación de Robert M. Grant sobre uno de los capítulos de su libro Contemporary Strategy Analysis en la que habla de las tendencias actuales en la gestión estratégica comparándolas con las que existían a finales de los 90 y comentando cómo nuevos aspectos, como la responsabilidad social corporativa, afectan a dicha estrategia.
Yo no puedo añadir mucho a un libro que se estudia en los mejores MBA del mundo, aunque, en mi humilde opinión, añadiría como factor actual en el entorno la "participación social/participación de los clientes". Algunos podrían considerarlo parte de otros aspectos, pero para mí tiene su propio peso, ya que influye en gran medida en las acciones de marketing y se refleja en temas tecnológicos propios de la Web 2.0 (blogs, marketing viral mediante redes sociales), o iniciativas hacia los usuarios o clientes como el tú eliges, tú decides y las oficinas cancha de la CAN, o el concurso de ideas del BBVA.
Yo no puedo añadir mucho a un libro que se estudia en los mejores MBA del mundo, aunque, en mi humilde opinión, añadiría como factor actual en el entorno la "participación social/participación de los clientes". Algunos podrían considerarlo parte de otros aspectos, pero para mí tiene su propio peso, ya que influye en gran medida en las acciones de marketing y se refleja en temas tecnológicos propios de la Web 2.0 (blogs, marketing viral mediante redes sociales), o iniciativas hacia los usuarios o clientes como el tú eliges, tú decides y las oficinas cancha de la CAN, o el concurso de ideas del BBVA.
lunes, 28 de abril de 2008
The Apprentice: Producción y Venta de Helados
En el capítulo de The Apprentice del miércoles pasado los equipos debían acudir a unas empresas productoras de helados localizadas en granjas, producir dos tipos de helados nuevos y venderlos en Londres. El que obtuviera mayores beneficios en las ventas ganaba.
Quizá para demostrar que no siempre el mejor jefe de proyecto obtiene los mejores resultados, en esta ocasión ganó el equipo con una jefa de proyecto con peores habilidades para la gestión. ¿Qué errores cometieron ambos equipos?
El equipo ganador:
1) La selección de los sabores para los helados implicaba que las materias primas necesarias fueran difíciles de encontrar. En el proceso de producción les ayudaba un empleado de la fábrica que les avisó del problema, pero decidieron seguir adelante. Debido a esto recorrieron varias millas buscando una tienda que tuviera naranjas fuera de temporada y perdieron bastante tiempo retrasando la producción de los helados y, por consiguiente, otras tareas.
2) Una falta absoluta de planificación hizo que no realizaran un buen estudio de mercado (reunir a gente a una hora en algún sitio para probar la gama de sabores y elegir dos) con lo que acabaron recurriendo a dos personas que se encontraban en un pub.
3) Aún peor fue la falta de previsión para concertar citas que les llevó a perder a uno de los posibles clientes que cerró el trato con el otro equipo.
Por suerte consiguieron una venta importante a última hora que les salvó.
El equipo perdedor:
1) El equipo de ventas ofreció exclusividad en los productos a 1 cadena de cines y a 1 de pubs, teniendo que cancelar citas posteriores y cerrándose clientes.
2) Concertaron citas con personas que no estaban interesadas en comprar pues hacían sus propios helados.
3) Se confiaron demasiado una vez habían cerrado sus primeros tratos.
Algunas soluciones evidentes para sus problemas:
A) Un análisis de riesgos llevaría a descubrir que las materias primas necesarias para el producto pueden no estar disponibles, pudiendo aplicar contramedidas (por ejemplo: más posibilidades de sabores para poder descartar)
B) Planificar adecuadamente las tareas detectando los productos implicados como lista de personas para un estudio de mercado o una lista de citas para vender productos (usando PBP).
C) No relajarse en el negocio pensando que se está por delante pues los competidores no descansan.
D) Definir una estrategia de ventas. Desgraciadamente, en este caso me temo que la jefa de proyecto no pudo hacer mucho más ya que por falta de tiempo delegó ventas en el grupo teóricamente más preparado para ello nombrando a una responsable. Esta responsable fue la expulsada en este programa.
Quizá para demostrar que no siempre el mejor jefe de proyecto obtiene los mejores resultados, en esta ocasión ganó el equipo con una jefa de proyecto con peores habilidades para la gestión. ¿Qué errores cometieron ambos equipos?
El equipo ganador:
1) La selección de los sabores para los helados implicaba que las materias primas necesarias fueran difíciles de encontrar. En el proceso de producción les ayudaba un empleado de la fábrica que les avisó del problema, pero decidieron seguir adelante. Debido a esto recorrieron varias millas buscando una tienda que tuviera naranjas fuera de temporada y perdieron bastante tiempo retrasando la producción de los helados y, por consiguiente, otras tareas.
2) Una falta absoluta de planificación hizo que no realizaran un buen estudio de mercado (reunir a gente a una hora en algún sitio para probar la gama de sabores y elegir dos) con lo que acabaron recurriendo a dos personas que se encontraban en un pub.
3) Aún peor fue la falta de previsión para concertar citas que les llevó a perder a uno de los posibles clientes que cerró el trato con el otro equipo.
Por suerte consiguieron una venta importante a última hora que les salvó.
El equipo perdedor:
1) El equipo de ventas ofreció exclusividad en los productos a 1 cadena de cines y a 1 de pubs, teniendo que cancelar citas posteriores y cerrándose clientes.
2) Concertaron citas con personas que no estaban interesadas en comprar pues hacían sus propios helados.
3) Se confiaron demasiado una vez habían cerrado sus primeros tratos.
Algunas soluciones evidentes para sus problemas:
A) Un análisis de riesgos llevaría a descubrir que las materias primas necesarias para el producto pueden no estar disponibles, pudiendo aplicar contramedidas (por ejemplo: más posibilidades de sabores para poder descartar)
B) Planificar adecuadamente las tareas detectando los productos implicados como lista de personas para un estudio de mercado o una lista de citas para vender productos (usando PBP).
C) No relajarse en el negocio pensando que se está por delante pues los competidores no descansan.
D) Definir una estrategia de ventas. Desgraciadamente, en este caso me temo que la jefa de proyecto no pudo hacer mucho más ya que por falta de tiempo delegó ventas en el grupo teóricamente más preparado para ello nombrando a una responsable. Esta responsable fue la expulsada en este programa.
viernes, 25 de abril de 2008
HP Labs recorta proyectos
El otro día comentábamos los planes de IBM en cuanto a innovación. Leo un artículo que comenta cómo HP va a recortar también el número de proyectos de 150 a unos 20 ó 30 manteniendo el mismo presupuesto, pero concentrándolo en lo más relevante desde el punto de vista económico. Critica también la falta de control en los proyectos hasta el momento. ¿Significará esto nuevos despidos?
Hablando de despidos, el caso de estudio de businessweek esta semana habla de un despido por mirar sitios X en el lugar de trabajo en EEUU. Lo más gracioso son los comentarios sobre las armas y, dentro del análisis la posibilidad de argumentar como enfermedad dicha conducta. Sorprendente.
Hablando de despidos, el caso de estudio de businessweek esta semana habla de un despido por mirar sitios X en el lugar de trabajo en EEUU. Lo más gracioso son los comentarios sobre las armas y, dentro del análisis la posibilidad de argumentar como enfermedad dicha conducta. Sorprendente.
jueves, 24 de abril de 2008
Educando en la gestión
En este último capítulo del reality de gestión de proyectos llamado The Apprentice descubrí que, después del programa, hay un análisis en el que un presentador, la persona expulsada y tres expertos comentan qué cosas fueron mal para que el perdedor del capítulo fuera despedido ("you're fired!").
Una cosa de la que no se les puede culpar a los ingleses es de intentar educar a sus ciudadanos en ser audaces, competitivos y emprendedores. Un ejemplo más lo tenemos en Dragons' Den donde un grupo de gente va con sus ideas o sus negocios a conseguir financiación de un grupo de 5 millonetis que les preguntan sobre los productos, previsiones, ROI ...
Respecto a lo de los análisis de The Apprentice, me queda el consuelo de que mis comentarios en el blog no sólo se relacionan con el perdedor, sino con ambos equipos (o al menos a partir de ahora).
Una cosa de la que no se les puede culpar a los ingleses es de intentar educar a sus ciudadanos en ser audaces, competitivos y emprendedores. Un ejemplo más lo tenemos en Dragons' Den donde un grupo de gente va con sus ideas o sus negocios a conseguir financiación de un grupo de 5 millonetis que les preguntan sobre los productos, previsiones, ROI ...
Respecto a lo de los análisis de The Apprentice, me queda el consuelo de que mis comentarios en el blog no sólo se relacionan con el perdedor, sino con ambos equipos (o al menos a partir de ahora).
martes, 22 de abril de 2008
IBM Case Study en businessweek.com
La semana pasada businessweek publicó Changing IBM's Innovation Strategy en la que describe y analiza
los pasos dados por el nuevo director de investigación para reorientar el I+D de IBM.
En estos meses John Kelly se ha dedicado a viajar por todos los centros de innovación (8) de IBM en el mundo recabando información de todos los investigadores acerca de los proyectos en los que se encontraban trabajando. Su conclusión ha sido que es necesario concentrar la inversión en innovación en un número más reducido de líneas de investigación, 4 en concreto, combinando proyectos a largo plazo (hasta 20 años) y a corto plazo (1-2 años). Esta decisión se debe a la actual situación en la que el presupuesto está distribuido entre demasiados proyectos.
La parte más compleja ha consistido en hacer a los investigadores y creativos adoptar el plan como propio sin que aquellos cuyas líneas de investigación desaparezcan se sientan relegados.
los pasos dados por el nuevo director de investigación para reorientar el I+D de IBM.
En estos meses John Kelly se ha dedicado a viajar por todos los centros de innovación (8) de IBM en el mundo recabando información de todos los investigadores acerca de los proyectos en los que se encontraban trabajando. Su conclusión ha sido que es necesario concentrar la inversión en innovación en un número más reducido de líneas de investigación, 4 en concreto, combinando proyectos a largo plazo (hasta 20 años) y a corto plazo (1-2 años). Esta decisión se debe a la actual situación en la que el presupuesto está distribuido entre demasiados proyectos.
La parte más compleja ha consistido en hacer a los investigadores y creativos adoptar el plan como propio sin que aquellos cuyas líneas de investigación desaparezcan se sientan relegados.
Motores de búsqueda y técnicas de posicionamiento
Uno de los métodos de marketing propios de la web es el denominado Search Engine Marketing (SEM). SEM incluye un conjunto de técnicas para posicionar adecuadamente un sitio web en los resultados de los motores de búsqueda como Google o Yahoo trabajando, entre otros aspectos, en la modificación de los componentes y relaciones del sitio. A este conjunto de técnicas de optimización se le denomina Search Engine Optimization (SEO).
A la hora de realizar las modificaciones necesarias al sitio, es necesario conocer el mercado, por ejemplo incluyendo las palabras clave más utilizadas en los motores de búsqueda o analizando la navegación de los usuarios por el propio sitio.
Algunas herramientas curiosas son socialmeter o aquellas que miden el Search Engine Saturation
A la hora de realizar las modificaciones necesarias al sitio, es necesario conocer el mercado, por ejemplo incluyendo las palabras clave más utilizadas en los motores de búsqueda o analizando la navegación de los usuarios por el propio sitio.
Algunas herramientas curiosas son socialmeter o aquellas que miden el Search Engine Saturation
viernes, 18 de abril de 2008
The Apprentice: Negocio fotográfico
En el capítulo de esta semana de este reality de gestión de proyectos que es The Apprentice, los equipos fueron divididos de una forma diferente, mezclando hombres y mujeres, y a la vez juntando personas con conflictos personales para ver la capacidad de los jefes de proyectos para gestionar un equipo ingobernable.
Los dos equipos, a los que llamaremos "ganador" y "perdedor", debían montar 1 expositor en un centro comercial predefinido con un negocio de fotografía en el que se atraerían a clientes para hacerse fotos. Evidentemente, para ganar debían obtener el máximo beneficio posible.
El equipo "ganador" se decidió por el mercado de familias con niños y jóvenes contratando a un doble de Beckham, mientras sus contrincantes buscaban un concepto "renacentista" venido a menos vistiendo a sus cliente con joyas de una de los miembros del equipo o con trajes supuestamente de época.
Ambos equipos cometieron errores básicos en el proceso de producción de las fotos que les hizo estar parados durante las horas de mayor afluencia de público.
La jefa de proyecto del equipo "ganador" decidió asignar a la gestión del ordenador para cargar las fotos e imprimirlas a la persona más desmotivada y que desde el principio confesó ser una negada técnica. Esto hizo que, aunque inicialmente iban a imprimir las fotos en tazas, puzzles y demás, al final sólo pudieron imprimirlas en papel (después de muchas vueltas) y entregárselas a los clientes así.
El equipo perdedor cometió numerosos errores (dejando a un lado su idea de mercado objetivo):
1) El proceso de producción fue un auténtico lío en el que no se sabía qué cliente había pedido qué foto(s) (había varias) y en qué formato. Así perdieron a numerosos clientes. El número de código de foto que daba la cámara no aparecía posteriormente en las imágenes exportadas al ordenador.
2) El jefe de proyecto no supo gestionar a un equipo difícil (en parte por culpa de uno de sus miembros) e irradiaba estrés y presión a lo largo de toda la prueba, a pesar de haberse presentado voluntario para el puesto.
Esto hizo que el equipo tuviera pérdidas y no beneficios.
Cosas que se hubieran podido hacer:
1) Probar el proceso de producción y refinarlo para encontrar los puntos débiles. Una prueba de 15 minutos en la hora de menor ocupación del centro comercial podría haber eliminado muchos de los problemas detectando los errores en el proceso de producción.
2) Analizar mejor el mercado. ¿Quiénes van a un centro comercial? ¿Quiénes estarían interesados en hacerse fotos? ¿Qué tipo de fotos? ¿Cuánto pagarían? La idea por la que optó el jefe de proyecto partió de su supuesto conocimiento de la zona y la gente que allí vivía, y de tener un amigo fotógrafo.
3) Hay gente cuyo carácter es una barrera para llegar a gestionar proyectos con éxito (no para ser jefe de proyecto). Para poder gestionar a gente difícil, primero tienes que aprender a gestionar tu tiempo, tu estrés y a ti mismo en general.
El expulsado fue el jefe de proyecto del equipo "perdedor", mientras que la persona que se rebelaba continuamente será jefa de proyecto la semana que viene.
Los dos equipos, a los que llamaremos "ganador" y "perdedor", debían montar 1 expositor en un centro comercial predefinido con un negocio de fotografía en el que se atraerían a clientes para hacerse fotos. Evidentemente, para ganar debían obtener el máximo beneficio posible.
El equipo "ganador" se decidió por el mercado de familias con niños y jóvenes contratando a un doble de Beckham, mientras sus contrincantes buscaban un concepto "renacentista" venido a menos vistiendo a sus cliente con joyas de una de los miembros del equipo o con trajes supuestamente de época.
Ambos equipos cometieron errores básicos en el proceso de producción de las fotos que les hizo estar parados durante las horas de mayor afluencia de público.
La jefa de proyecto del equipo "ganador" decidió asignar a la gestión del ordenador para cargar las fotos e imprimirlas a la persona más desmotivada y que desde el principio confesó ser una negada técnica. Esto hizo que, aunque inicialmente iban a imprimir las fotos en tazas, puzzles y demás, al final sólo pudieron imprimirlas en papel (después de muchas vueltas) y entregárselas a los clientes así.
El equipo perdedor cometió numerosos errores (dejando a un lado su idea de mercado objetivo):
1) El proceso de producción fue un auténtico lío en el que no se sabía qué cliente había pedido qué foto(s) (había varias) y en qué formato. Así perdieron a numerosos clientes. El número de código de foto que daba la cámara no aparecía posteriormente en las imágenes exportadas al ordenador.
2) El jefe de proyecto no supo gestionar a un equipo difícil (en parte por culpa de uno de sus miembros) e irradiaba estrés y presión a lo largo de toda la prueba, a pesar de haberse presentado voluntario para el puesto.
Esto hizo que el equipo tuviera pérdidas y no beneficios.
Cosas que se hubieran podido hacer:
1) Probar el proceso de producción y refinarlo para encontrar los puntos débiles. Una prueba de 15 minutos en la hora de menor ocupación del centro comercial podría haber eliminado muchos de los problemas detectando los errores en el proceso de producción.
2) Analizar mejor el mercado. ¿Quiénes van a un centro comercial? ¿Quiénes estarían interesados en hacerse fotos? ¿Qué tipo de fotos? ¿Cuánto pagarían? La idea por la que optó el jefe de proyecto partió de su supuesto conocimiento de la zona y la gente que allí vivía, y de tener un amigo fotógrafo.
3) Hay gente cuyo carácter es una barrera para llegar a gestionar proyectos con éxito (no para ser jefe de proyecto). Para poder gestionar a gente difícil, primero tienes que aprender a gestionar tu tiempo, tu estrés y a ti mismo en general.
El expulsado fue el jefe de proyecto del equipo "perdedor", mientras que la persona que se rebelaba continuamente será jefa de proyecto la semana que viene.
miércoles, 16 de abril de 2008
Tolerancias estándar en un proyecto
Hoy me he decidido a hablar de las tolerancias que existen en el ámbito de un proyecto. La tolerancia no es más que un mecanismo de control que permite al director de proyecto tener una cierta flexibilidad siempre y cuando no se prevea que se van a sobrepasar los límites establecidos.
Prince2 define dos tolerancias estándar de un proyecto: coste y tiempo. Estas tolerancias se aplican tanto al plan de proyecto como al de las diversas etapas que lo forman. Mientras que la tolerancia del plan de proyecto viene impuesta desde la propia organización (o programa si el proyecto es parte de uno), las de las etapas las establece la Junta de Proyecto al inicio de cada una.
Un ejemplo sería "El proyecto ha de estar acabado el 21 de Diciembre +1/-2 semanas" o "ha de costar 100000 euros +/- 5%". Como se ve, es posible establecer distintos valores para tolerancias positivas o negativas. El hecho de definir tolerancias negativas en coste permite detectar presupuesto adicional disponible si se supera dicho límite, facilitando su redistribución o habilitando nuevos proyectos. En cuanto a tiempo, una tolerancia negativa permitiría adelantar otros proyectos o valorar gastos extra como, por ejemplo, establecer costes adicionales de almacenaje de los bienes producidos.
Además de estas tolerancias, existen otras como la tolerancia en el ámbito del proyecto, tolerancia a los riesgos, tolerancia en términos de beneficios o tolerancia de calidad. De estas otras hablaré en una entrada distinta.
Prince2 define dos tolerancias estándar de un proyecto: coste y tiempo. Estas tolerancias se aplican tanto al plan de proyecto como al de las diversas etapas que lo forman. Mientras que la tolerancia del plan de proyecto viene impuesta desde la propia organización (o programa si el proyecto es parte de uno), las de las etapas las establece la Junta de Proyecto al inicio de cada una.
Un ejemplo sería "El proyecto ha de estar acabado el 21 de Diciembre +1/-2 semanas" o "ha de costar 100000 euros +/- 5%". Como se ve, es posible establecer distintos valores para tolerancias positivas o negativas. El hecho de definir tolerancias negativas en coste permite detectar presupuesto adicional disponible si se supera dicho límite, facilitando su redistribución o habilitando nuevos proyectos. En cuanto a tiempo, una tolerancia negativa permitiría adelantar otros proyectos o valorar gastos extra como, por ejemplo, establecer costes adicionales de almacenaje de los bienes producidos.
Además de estas tolerancias, existen otras como la tolerancia en el ámbito del proyecto, tolerancia a los riesgos, tolerancia en términos de beneficios o tolerancia de calidad. De estas otras hablaré en una entrada distinta.
martes, 15 de abril de 2008
CIO y MBA
¿Debe tener un CIO un MBA? Esta es la pregunta que se plantean en este artículo. Echando un vistazo a las ofertas de Londres relacionadas con ese perfil lo que piden es experiencia en dicho puesto más que una formación determinada.
Algunos otros artículos relacionados aquí y aquí.
Algunos otros artículos relacionados aquí y aquí.
lunes, 14 de abril de 2008
The Apprentice: Gestión de un Restaurante
Por fin he visto el último capítulo de The Apprentice a través de la web de la BBC. En él los participantes, divididos de nuevo en hombres vs. mujeres, tenían como misión convertir un Pub durante un día (almuerzo y cena) en un restaurante temático y obtener el máximo beneficio, para lo que disponían de un presupuesto inicial y una lista de proveedores de alimentos.
En esta ocasión perdieron los hombres que decidieron optar por un tema sencillo como es montar un restaurante italiano frente a las mujeres que lo hicieron muy bien con comida india. Los principales problemas del equipo masculino fueron:
1) Nula gestión de compras con un gasto excesivo en la alimentación y en el marketing. El gasto en alimentación se debió a que no realizaron los pedidos el primer día con lo que tuvieron que realizar las compras en un supermercado en vez de acudir a los proveedores.
2) Fallo al establecer los márgenes comerciales (precio del menú vs. gastos realizados).
Lo que resultó en que facturaron más que el otro equipo, pero tuvieron la mitad de beneficio.
Algunas acciones podrían haberse completado para evitar los problemas mencionados anteriormente.
1) Una correcta planificación de tareas con plazos habría permitido detectar los límites de plazos para tratar con proveedores y la necesidad de cerrar las tareas en un tiempo determinado (identificando las tareas críticas). El gasto en alimentación se habría reducido, incrementando el beneficio final. Además, el equipo masculino optó por gastar una cantidad mayor de dinero en marketing (menús especiales con la bandera de Italia) lo cual debería haber repercutido en el precio final del producto.
2) Otro error de planificación básico en el que se decidió el precio de los platos del menú y se imprimió el mismo sin conocer siquiera el coste de los productos que se debían comprar.
Para ambas partes, una planificación basada en producto hubiera facilitado una clara solución.
Cabe destacar que el equipo femenino, aunque cometió errores que le impidieron servir el almuerzo, realizó algunas acciones muy originales como:
- Vender el día anterior vales de descuento para la cena (por ejemplo: a 3 EUR un descuento de 5 EUR) con lo que antes de empezar a hacer nada ya disponían de un beneficio asegurado. Algunos de los compradores ni siquiera se presentaron a cenar.
- Todas las acciones de marketing les salieron gratis ya que convencieron a los distintos proveedores locales de imprimirles los vales y dejarles los elementos decorativos y trajes para la cena a cambio de poner publicidad de sus distintos comercios.
El expulsado fue el jefe de proyecto que se empeñó en culpar al único que se había atrevido a decirle que debían basar sus decisiones en datos, datos, datos.
En esta ocasión perdieron los hombres que decidieron optar por un tema sencillo como es montar un restaurante italiano frente a las mujeres que lo hicieron muy bien con comida india. Los principales problemas del equipo masculino fueron:
1) Nula gestión de compras con un gasto excesivo en la alimentación y en el marketing. El gasto en alimentación se debió a que no realizaron los pedidos el primer día con lo que tuvieron que realizar las compras en un supermercado en vez de acudir a los proveedores.
2) Fallo al establecer los márgenes comerciales (precio del menú vs. gastos realizados).
Lo que resultó en que facturaron más que el otro equipo, pero tuvieron la mitad de beneficio.
Algunas acciones podrían haberse completado para evitar los problemas mencionados anteriormente.
1) Una correcta planificación de tareas con plazos habría permitido detectar los límites de plazos para tratar con proveedores y la necesidad de cerrar las tareas en un tiempo determinado (identificando las tareas críticas). El gasto en alimentación se habría reducido, incrementando el beneficio final. Además, el equipo masculino optó por gastar una cantidad mayor de dinero en marketing (menús especiales con la bandera de Italia) lo cual debería haber repercutido en el precio final del producto.
2) Otro error de planificación básico en el que se decidió el precio de los platos del menú y se imprimió el mismo sin conocer siquiera el coste de los productos que se debían comprar.
Para ambas partes, una planificación basada en producto hubiera facilitado una clara solución.
Cabe destacar que el equipo femenino, aunque cometió errores que le impidieron servir el almuerzo, realizó algunas acciones muy originales como:
- Vender el día anterior vales de descuento para la cena (por ejemplo: a 3 EUR un descuento de 5 EUR) con lo que antes de empezar a hacer nada ya disponían de un beneficio asegurado. Algunos de los compradores ni siquiera se presentaron a cenar.
- Todas las acciones de marketing les salieron gratis ya que convencieron a los distintos proveedores locales de imprimirles los vales y dejarles los elementos decorativos y trajes para la cena a cambio de poner publicidad de sus distintos comercios.
El expulsado fue el jefe de proyecto que se empeñó en culpar al único que se había atrevido a decirle que debían basar sus decisiones en datos, datos, datos.
sábado, 12 de abril de 2008
Días en España
Acabo de volver de España, donde he estado realizando algunos trámites y reuniones con clientes, lo cual me ha impedido ver el último capítulo de The Apprentice, aunque intentaré descargármelo con el iPlayer de la BBC para poder comentarlo.
La buena noticia ha sido la carta comentándome que he pasado el examen y ya soy Prince2 Practitioner.
La buena noticia ha sido la carta comentándome que he pasado el examen y ya soy Prince2 Practitioner.
viernes, 11 de abril de 2008
Comité (o Junta) de Proyecto
Hoy he decidido comentar brevemente la composición e importancia de contar con un Project Board. Echando un vistazo al glosario de Prince2 al castellano, he visto que se ha traducido el término Project Board como Junta de Proyecto.
Como lo importante no es tanto el continente como el contenido, me concedo la libertad de usar términos ingleses para Prince2 puesto que son los que aprendí en su momento.
La organización en cuanto a un proyecto en Prince2 se basa en la existencia de niveles o capas de decisión que controlan a los niveles de decisión que se encuentran bajo su responsabilidad. Así, la dirección corporativa o de programa controla al Project Board, que a su vez controla y aconseja al Project Manager, que puede controlar a los Team Managers si éstos existen (dependerá del tamaño del proyecto y de la existencia de proveedores externos).
El Project Board está formado, al menos, por tres roles que equivalen a tres dominios diferentes: el Executive (negocio), el Senior User (usuarios) y el Senior Supplier (proveedores). Otros roles pueden aparecer según el tipo y características del proyecto (por ejemplo un representante del programa o del ente financiador).
La gestión del Project Board en Prince2 es una gestión por excepción. Esto quiere decir que el Project Manager se encarga del día a día del mismo y que existen controles que permiten actuar al Project Board cuando es necesario. Algunos de estos controles son 1) la división del proyecto en etapas donde se revisa la validez del Business Case y se realiza una evaluación del proyecto ante el Project Board, 2) la asignación de tolerancias en cuanto a tiempo y coste de las etapas del proyecto, 3) informes periódicos enviados por el Project Manager ó 4) informes de excepción cuando se prevé que se superará la tolerancia asignada.
Dentro del Project Board, el Executive es el propietario del Business Case y el responsable último de tomar decisiones tales como dar luz verde al proyecto e invertir recursos en el mismo. El Senior User y el Senior Supplier actúan como representantes de sus respectivos dominios y aconsejan al Executive acerca del proyecto desde sus perspectivas.
El Senior User ha de asegurar que se proporciona toda la ayuda necesaria por parte de los usuarios a la vez que comprueba que el proyecto proporciona los resultados requeridos. El Senior Supplier responde de la capacidad de los proveedores para proporcionar los recursos adecuados y se asegura de que sus objetivos de negocio se cumplan.
Como lo importante no es tanto el continente como el contenido, me concedo la libertad de usar términos ingleses para Prince2 puesto que son los que aprendí en su momento.
La organización en cuanto a un proyecto en Prince2 se basa en la existencia de niveles o capas de decisión que controlan a los niveles de decisión que se encuentran bajo su responsabilidad. Así, la dirección corporativa o de programa controla al Project Board, que a su vez controla y aconseja al Project Manager, que puede controlar a los Team Managers si éstos existen (dependerá del tamaño del proyecto y de la existencia de proveedores externos).
El Project Board está formado, al menos, por tres roles que equivalen a tres dominios diferentes: el Executive (negocio), el Senior User (usuarios) y el Senior Supplier (proveedores). Otros roles pueden aparecer según el tipo y características del proyecto (por ejemplo un representante del programa o del ente financiador).
La gestión del Project Board en Prince2 es una gestión por excepción. Esto quiere decir que el Project Manager se encarga del día a día del mismo y que existen controles que permiten actuar al Project Board cuando es necesario. Algunos de estos controles son 1) la división del proyecto en etapas donde se revisa la validez del Business Case y se realiza una evaluación del proyecto ante el Project Board, 2) la asignación de tolerancias en cuanto a tiempo y coste de las etapas del proyecto, 3) informes periódicos enviados por el Project Manager ó 4) informes de excepción cuando se prevé que se superará la tolerancia asignada.
Dentro del Project Board, el Executive es el propietario del Business Case y el responsable último de tomar decisiones tales como dar luz verde al proyecto e invertir recursos en el mismo. El Senior User y el Senior Supplier actúan como representantes de sus respectivos dominios y aconsejan al Executive acerca del proyecto desde sus perspectivas.
El Senior User ha de asegurar que se proporciona toda la ayuda necesaria por parte de los usuarios a la vez que comprueba que el proyecto proporciona los resultados requeridos. El Senior Supplier responde de la capacidad de los proveedores para proporcionar los recursos adecuados y se asegura de que sus objetivos de negocio se cumplan.
lunes, 7 de abril de 2008
Presupuesto de Cambios
Uno de los elementos que pueden influir más sobre el éxito de un proyecto es la gestión de los cambios que se puedan producir durante su ejecución.
En proyectos software en los que los requisitos cambian de forma continuada, existen las llamadas metodologías Agile (XP, Scrum...), que tienden a proporcionar una mayor flexibilidad mediante el uso de iteraciones en la generación del producto final (aunque han recibido también críticas).
Desde un punto de vista más genérico, una de las primeras cosas a decidir en un proyecto es el proceso que se seguirá para gestionar los cambios. Esto incluye identificar si algo es un cambio real o no (algo que he visto más de una vez discutir entre el proveedor y el cliente), si dicho cambio es necesario o si se llevará a cabo dentro del proyecto en curso.
Las metodologías de gestión de proyectos (como Prince2) sugieren la figura de una Autoridad de Cambio, que se encargue de tomar las decisiones acerca de si se aborda o no un cambio dentro de un proyecto. Para facilitar su gestión, se crearía al inicio del proyecto una partida para este tipo de circunstancias denominada Presupuesto de Cambios.
Es importante entender que las tolerancias dadas a un proyecto (como tiempo o coste) nunca deben usarse por el jefe de proyecto para realizar un cambio solicitado en un momento dado del proyecto. Estos cambios deben seguir un proceso de aceptación (más o menos formal) y deben ser financiados con el Presupuesto de Cambios o, en caso de no ser posible, se ha de valorar cómo afecta la implantación/no implantación del cambio al Business Case, remitiendo el problema al nivel de gestión inmediatamente superior (en Prince2 es el Project Board o Junta de Proyecto).
En proyectos software en los que los requisitos cambian de forma continuada, existen las llamadas metodologías Agile (XP, Scrum...), que tienden a proporcionar una mayor flexibilidad mediante el uso de iteraciones en la generación del producto final (aunque han recibido también críticas).
Desde un punto de vista más genérico, una de las primeras cosas a decidir en un proyecto es el proceso que se seguirá para gestionar los cambios. Esto incluye identificar si algo es un cambio real o no (algo que he visto más de una vez discutir entre el proveedor y el cliente), si dicho cambio es necesario o si se llevará a cabo dentro del proyecto en curso.
Las metodologías de gestión de proyectos (como Prince2) sugieren la figura de una Autoridad de Cambio, que se encargue de tomar las decisiones acerca de si se aborda o no un cambio dentro de un proyecto. Para facilitar su gestión, se crearía al inicio del proyecto una partida para este tipo de circunstancias denominada Presupuesto de Cambios.
Es importante entender que las tolerancias dadas a un proyecto (como tiempo o coste) nunca deben usarse por el jefe de proyecto para realizar un cambio solicitado en un momento dado del proyecto. Estos cambios deben seguir un proceso de aceptación (más o menos formal) y deben ser financiados con el Presupuesto de Cambios o, en caso de no ser posible, se ha de valorar cómo afecta la implantación/no implantación del cambio al Business Case, remitiendo el problema al nivel de gestión inmediatamente superior (en Prince2 es el Project Board o Junta de Proyecto).
sábado, 5 de abril de 2008
LinkedIn, Businessweek.con y Capital IQ
Leo en Businessweek.com que LinkedIn ha llegado a un acuerdo con dicho sitio web y con Capital IQ de forma que ahora al pulsar en el nombre de una empresa en LinkedIn (al mirar en el perfil de una persona, por ejemplo) se accede a información sobre la misma proporcionada por dichas fuentes.
A cambio, los lectores de businessweek.com, al leer un artículo relacionado con una empresa concreta, pueden acceder a la información de sus contactos en LinkedIn en esas compañías.
Yo ya lo he probado en LinkedIn y la información me parece muy interesante cuando se trata de grandes empresas.
A cambio, los lectores de businessweek.com, al leer un artículo relacionado con una empresa concreta, pueden acceder a la información de sus contactos en LinkedIn en esas compañías.
Yo ya lo he probado en LinkedIn y la información me parece muy interesante cuando se trata de grandes empresas.
viernes, 4 de abril de 2008
El Visionario Práctico
Leo en la revista Strategic+Business un artículo llamado The Practical Visionary que comenta la importancia creciente de los CIO en la planificación de la estrategia de la empresa en un entorno lleno de nuevas tecnologías capaces de hacer posibles objetivos impensables con anterioridad. El artículo habla de cómo muchos de los CIO tienen una doble labor negocio-estratégica y técnico-operacional lo que me recuerda otro artículo ya antiguo que comentaba la posible relación entre los roles de CIO y CTO.
Volviendo al artículo inicial, pone algunos ejemplos y explica cómo se evalúa en las empresas la posibilidad de utilizar mecanismos de la Web 2.0 (no me gustó nunca este término de marketing), como las redes sociales o las nubes de etiquetas (tag cloud), en la relación interna de la empresa o en la relación con sus clientes. Ante un panorama lleno de nuevas tecnologías y soluciones, es necesario generar una estrategia de negocio basada en ellas seleccionando las adecuadas para cada aspecto.
A su vez es necesario un enfoque holístico e integrado de los sistemas a desarrollar para evitar problemas bien conocidos de desarrollos (o herramientas) no integrados que hacen imposible obtener una información completa sobre la situación del negocio. Este enfoque ha de tener en cuenta la forma en que los usuarios utilizan las tecnologías y sus preferencias para evitar producir herramientas que acaben siendo rechazadas o utilizadas de forma inadecuada.
Volviendo al artículo inicial, pone algunos ejemplos y explica cómo se evalúa en las empresas la posibilidad de utilizar mecanismos de la Web 2.0 (no me gustó nunca este término de marketing), como las redes sociales o las nubes de etiquetas (tag cloud), en la relación interna de la empresa o en la relación con sus clientes. Ante un panorama lleno de nuevas tecnologías y soluciones, es necesario generar una estrategia de negocio basada en ellas seleccionando las adecuadas para cada aspecto.
A su vez es necesario un enfoque holístico e integrado de los sistemas a desarrollar para evitar problemas bien conocidos de desarrollos (o herramientas) no integrados que hacen imposible obtener una información completa sobre la situación del negocio. Este enfoque ha de tener en cuenta la forma en que los usuarios utilizan las tecnologías y sus preferencias para evitar producir herramientas que acaben siendo rechazadas o utilizadas de forma inadecuada.
Lavandería en The Apprentice
Esta semana, el reto en "The Apprentice" consistía en conseguir gestionar un negocio de lavandería durante un día. Para ello, se les había asignado a los dos equipos un local ya habilitado a tal efecto y un par de citas para conseguir algo de negocio en las que debían competir por los clientes. El resto consistía en encontrar negocio adicional y lavar la ropa antes de las 2 de la madrugada.
En esta ocasión, fue el equipo femenino el que perdió (la semana pasada el masculino). A mi entender, los principales errores fueron los siguientes:
1) Ignorancia acerca del rango de precios que debían cobrar sugiriéndole al cliente de la primera cita que se gastara 20 veces más de lo que pagaba habitualmente (era un hotel y costaba más lavar la ropa de cama que comprarla nueva). Al segundo cliente (el dueño de una pescadería) se lo pusieron tan barato que no paraba de decir "¿estáis seguras?".
2) Falta de visión acerca del tipo de mercado al que orientarse. Encontrándose con que perdieron mucho tiempo visitando casa por casa en el lugar inadecuado.
3) Pérdida de ropa de los clientes debido a que la responsable se ausentó a la mitad y a fallos en el proceso de etiquetado. Parece ser que algunas etiquetas se soltaron durante el lavado y nadie sabía a quién pertenecía la ropa. La jefa de proyecto estaba junto a otros miembros de su equipo intentando conseguir más negocio. La responsable del proceso no se encontraba allí pues había decidido que necesitaban más planchas para poder acabar a tiempo y se había ido a conseguirlas.
Además, 4) como viene siendo habitual en esta serie, la jefa de proyecto viéndolas venir decidió buscar un culpable. Su conducta como jefa de proyecto no fue la más adecuada a mi entender puesto que la sensación ofrecida era que, intentaba parecer ante las cámaras que gestionaba, en vez de gestionar realmente (algo muy común en algunas empresas si cambias cámara por director).
¿Qué podía haber hecho la jefa de proyecto para corregir estos problemas?
1) Averiguar en vez de adivinar. Es un poco elemental, pero parece que lo de estudiar a la competencia no es algo que haga todo el mundo. El otro equipo llamó a una lavandería (usando simplemente las páginas amarillas) y obtuvo un precio que le sirvió de referencia para negociar con el cliente.
2) Quizá lo más difícil de hacer en tan poco tiempo es analizar el mercado. No obstante, siempre es bueno dedicarle un rato para decidir cosas como "mercado residencial vs. comercial". Escuchar al equipo siempre ayuda, animar a que proporcionen ideas, cuando entre ellos se supone que tienes expertos en ventas, marketing y dirección, aunque sea el jefe de proyecto el que tome la decisión final.
3) Es cierto que la persona responsable del etiquetado se ausentó (fue a la que echaron finalmente), pero como jefe de proyecto has de valorar qué procesos son más importantes y cuáles tienen riesgos a los que hay que dar una respuesta. En este caso, los riesgos, entre otros, eran que el proceso de etiquetado fallara, que la persona responsable faltara. Una acción muy sencilla hubiera sido hacer a más de una persona participar en el proceso (manteniendo un responsable). ¿Qué contramedidas hubierais utilizado?
4) Lo importante es que gestiones el proyecto. Al final de lo que se van a acordar es del resultado del mismo. ¿Fue un proyecto exitoso? Si no, ¿supiste identificar los problemas? ¿Aprendiste algo nuevo?
¿Tendría éxito un programa así en España? Una de las cosas que me sorprende gratamente de la gente de Gran Bretaña es la predisposición a crear su propia empresa. A veces de forma un poco "naïve".
Más la semana que viene.
En esta ocasión, fue el equipo femenino el que perdió (la semana pasada el masculino). A mi entender, los principales errores fueron los siguientes:
1) Ignorancia acerca del rango de precios que debían cobrar sugiriéndole al cliente de la primera cita que se gastara 20 veces más de lo que pagaba habitualmente (era un hotel y costaba más lavar la ropa de cama que comprarla nueva). Al segundo cliente (el dueño de una pescadería) se lo pusieron tan barato que no paraba de decir "¿estáis seguras?".
2) Falta de visión acerca del tipo de mercado al que orientarse. Encontrándose con que perdieron mucho tiempo visitando casa por casa en el lugar inadecuado.
3) Pérdida de ropa de los clientes debido a que la responsable se ausentó a la mitad y a fallos en el proceso de etiquetado. Parece ser que algunas etiquetas se soltaron durante el lavado y nadie sabía a quién pertenecía la ropa. La jefa de proyecto estaba junto a otros miembros de su equipo intentando conseguir más negocio. La responsable del proceso no se encontraba allí pues había decidido que necesitaban más planchas para poder acabar a tiempo y se había ido a conseguirlas.
Además, 4) como viene siendo habitual en esta serie, la jefa de proyecto viéndolas venir decidió buscar un culpable. Su conducta como jefa de proyecto no fue la más adecuada a mi entender puesto que la sensación ofrecida era que, intentaba parecer ante las cámaras que gestionaba, en vez de gestionar realmente (algo muy común en algunas empresas si cambias cámara por director).
¿Qué podía haber hecho la jefa de proyecto para corregir estos problemas?
1) Averiguar en vez de adivinar. Es un poco elemental, pero parece que lo de estudiar a la competencia no es algo que haga todo el mundo. El otro equipo llamó a una lavandería (usando simplemente las páginas amarillas) y obtuvo un precio que le sirvió de referencia para negociar con el cliente.
2) Quizá lo más difícil de hacer en tan poco tiempo es analizar el mercado. No obstante, siempre es bueno dedicarle un rato para decidir cosas como "mercado residencial vs. comercial". Escuchar al equipo siempre ayuda, animar a que proporcionen ideas, cuando entre ellos se supone que tienes expertos en ventas, marketing y dirección, aunque sea el jefe de proyecto el que tome la decisión final.
3) Es cierto que la persona responsable del etiquetado se ausentó (fue a la que echaron finalmente), pero como jefe de proyecto has de valorar qué procesos son más importantes y cuáles tienen riesgos a los que hay que dar una respuesta. En este caso, los riesgos, entre otros, eran que el proceso de etiquetado fallara, que la persona responsable faltara. Una acción muy sencilla hubiera sido hacer a más de una persona participar en el proceso (manteniendo un responsable). ¿Qué contramedidas hubierais utilizado?
4) Lo importante es que gestiones el proyecto. Al final de lo que se van a acordar es del resultado del mismo. ¿Fue un proyecto exitoso? Si no, ¿supiste identificar los problemas? ¿Aprendiste algo nuevo?
¿Tendría éxito un programa así en España? Una de las cosas que me sorprende gratamente de la gente de Gran Bretaña es la predisposición a crear su propia empresa. A veces de forma un poco "naïve".
Más la semana que viene.
jueves, 3 de abril de 2008
Planificación basada en producto
A veces a uno le da vergüenza decir cosas tan triviales y evidentes como que todas las actividades de un proyecto deben ir orientadas a la consecución de los objetivos del mismo. Y digo que me da vergüenza no porque sea algo que sobre decir, sino por la cantidad de gente que se pierde en tareas superfluas e innecesarias.
Una de las técnicas que más ayudan a evitar tal abominación consiste en la planificación basada en producto. Es recomendada por metodologías como Prince2.
La idea consiste en la definición de productos, partiendo del que se obtendrá como resultado del proyecto. Un producto puede ser algo físico, un documento, algo electrónico o incluso algo intangible como un cambio de cultura empresarial o un cambio organizacional.
El primer paso consiste en generar para el producto final lo que se denomina una Descripción de Producto que incluye aspectos tan variados como su nombre, resumen, identificador (gestión de configuración), su propietario, origen (de dónde se obtiene o quién lo crea) o aspectos relacionados con su calidad como criterios, métodos y revisores.
A partir de dicho producto se genera una Estructura de Desglose de Productos donde se sitúa el producto final en la parte superior y se construye una estructura con los productos que lo forman en un árbol jerárquico. Estos productos pueden ser externos, integración de otros productos, productos simples o agrupaciones, existiendo diferentes símbolos para cada tipo.
Con unos dos niveles de profundidad en la estructura (dependerá del proyecto) se recomienda crear la descripción de los productos identificados.
Finalmente, se construye un Diagrama de Flujo de Productos que representa mediante flechas las dependencias entre los productos encontrados hasta llegar al producto final al que deben ir a parar todos los caminos.
Este proceso es iterativo pues se pueden dar situaciones como que el desarrollo del Diagrama de Flujo de Productos nos permita identificar productos adicionales. El proceso completo con sus iteraciones se da cada vez que se realiza una planificación incluyendo el plan de proyecto o el plan de las diferentes etapas del mismo.
Una vez que se dispone del Diagrama de Flujo de Productos, las flechas indican transformaciones que se deben realizar para generar un producto. Estas transformaciones se harán coincidir con actividades y así habremos evitado el problema de realizar tareas innecesarias para el éxito del proyecto.
Frente al enfoque tradicional de Estructura de Desglose de Trabajo (Work Breakdown Structure), la planificación basada en producto y la Estructura de Desglose de Productos (Product Breakdown Structure) van un paso más allá proporcionando valor a las tareas a partir de su contribución al producto final.
Una de las técnicas que más ayudan a evitar tal abominación consiste en la planificación basada en producto. Es recomendada por metodologías como Prince2.
La idea consiste en la definición de productos, partiendo del que se obtendrá como resultado del proyecto. Un producto puede ser algo físico, un documento, algo electrónico o incluso algo intangible como un cambio de cultura empresarial o un cambio organizacional.
El primer paso consiste en generar para el producto final lo que se denomina una Descripción de Producto que incluye aspectos tan variados como su nombre, resumen, identificador (gestión de configuración), su propietario, origen (de dónde se obtiene o quién lo crea) o aspectos relacionados con su calidad como criterios, métodos y revisores.
A partir de dicho producto se genera una Estructura de Desglose de Productos donde se sitúa el producto final en la parte superior y se construye una estructura con los productos que lo forman en un árbol jerárquico. Estos productos pueden ser externos, integración de otros productos, productos simples o agrupaciones, existiendo diferentes símbolos para cada tipo.
Con unos dos niveles de profundidad en la estructura (dependerá del proyecto) se recomienda crear la descripción de los productos identificados.
Finalmente, se construye un Diagrama de Flujo de Productos que representa mediante flechas las dependencias entre los productos encontrados hasta llegar al producto final al que deben ir a parar todos los caminos.
Este proceso es iterativo pues se pueden dar situaciones como que el desarrollo del Diagrama de Flujo de Productos nos permita identificar productos adicionales. El proceso completo con sus iteraciones se da cada vez que se realiza una planificación incluyendo el plan de proyecto o el plan de las diferentes etapas del mismo.
Una vez que se dispone del Diagrama de Flujo de Productos, las flechas indican transformaciones que se deben realizar para generar un producto. Estas transformaciones se harán coincidir con actividades y así habremos evitado el problema de realizar tareas innecesarias para el éxito del proyecto.
Frente al enfoque tradicional de Estructura de Desglose de Trabajo (Work Breakdown Structure), la planificación basada en producto y la Estructura de Desglose de Productos (Product Breakdown Structure) van un paso más allá proporcionando valor a las tareas a partir de su contribución al producto final.
miércoles, 2 de abril de 2008
El Aprendiz
Para los que no lo sepan, "The apprentice" es un programa que se emite en países anglosajones (la NBC en EEUU y la BBC1 en Gran Bretaña) que consiste en una especie de Reality Show en el que un grupo de personas compiten para llegar a ser contratados como managers por un tío millonario (en Gran Bretaña es Sir Alan Sugar) con un sueldo de 6 cifras. Para ello, cada semana se dividen en dos grupos y se elige un jefe de proyecto. Los dos grupos han de competir en una prueba tipo "vendedme esta furgoneta llena de pescado en un mercado de Londres obteniendo el máximo beneficio posible y sin que quede ni uno solo". El jefe de proyecto del grupo perdedor selecciona a los dos miembros de su equipo que considera que lo han hecho peor y el millonario decide echar a uno de los tres.
Con todos sus defectos como típico Reality Show que es (gente sobreactuando, énfasis en las peleas internas, tejemanejes por detrás que no se ven para hacerles fallar ...) lo que realmente me llama la atención es la capacidad de aprender de la cantidad de errores que se pueden producir siendo (project) manager y que se muestran en ese programa. En estas pruebas no siempre gana el que mejor lo hace, puesto que existe un factor suerte y la calidad del equipo influye mucho.
En el último programa (en el que vendían el pescado), el equipo perdedor falló por tres razones principalmente:
1) Demasiado tiempo gastado en tareas menos importantes como elegir el nombre del equipo lo que les llevó a llegar tarde al mercado;
2) Error a la hora de etiquetar tres tipos de pescados (tenían un librito en el que había fotos y nombres);
y 3) Error a la hora de poner precio a las langostas (¡hasta yo las habría comprado a mitad de precio!).
Además, 4) al descubrir los errores el jefe de proyecto decidió buscar responsables y no soluciones.
¿Qué podría haber hecho el jefe de proyecto para evitarlo?
1) Priorizar tareas y fijar un tiempo máximo para las menos importantes adoptando una decisión en caso necesario.
2y3) Calidad, calidad y calidad. Toda metodología de gestión de proyectos incluye controlar la calidad de los productos (intermedios y finales) que se generan en el proyecto. Si el jefe de proyecto hubiera asignado a una persona que comprobara el etiquetado de pescados y a una segunda que comprobara los precios (evidentemente distintas de las que lo hicieron originalmente) los problemas se hubieran reducido.
4) Independiéntemente de quién comete un error, como jefe de proyecto eres el responsable último ya que tú asignaste dicha tarea. Si hubieras hecho 2y3) no te encontrarías en esta situación. En un programa como "The Apprentice" buscas que la gente sepa quién es el que comete los errores para encontrar un cabeza de turco, pero un jefe medio despierto es capaz de leer entre líneas, así que con todo eso sólo provocas división en tu equipo sin ningún beneficio para ti (el jefe de proyecto ya tiene enemigos para las próximas semanas). Siempre hay que buscar soluciones y no responsables, lo que no quiere decir que no debamos aprender de nuestros errores.
Del equipo ganador no hablo, aunque cometió casi más errores que el perdedor, con falta de liderazgo, sin repartir responsabilidades, sin poner precios fijos por el pescado, sin comprobar la competencia ...
Con todos sus defectos como típico Reality Show que es (gente sobreactuando, énfasis en las peleas internas, tejemanejes por detrás que no se ven para hacerles fallar ...) lo que realmente me llama la atención es la capacidad de aprender de la cantidad de errores que se pueden producir siendo (project) manager y que se muestran en ese programa. En estas pruebas no siempre gana el que mejor lo hace, puesto que existe un factor suerte y la calidad del equipo influye mucho.
En el último programa (en el que vendían el pescado), el equipo perdedor falló por tres razones principalmente:
1) Demasiado tiempo gastado en tareas menos importantes como elegir el nombre del equipo lo que les llevó a llegar tarde al mercado;
2) Error a la hora de etiquetar tres tipos de pescados (tenían un librito en el que había fotos y nombres);
y 3) Error a la hora de poner precio a las langostas (¡hasta yo las habría comprado a mitad de precio!).
Además, 4) al descubrir los errores el jefe de proyecto decidió buscar responsables y no soluciones.
¿Qué podría haber hecho el jefe de proyecto para evitarlo?
1) Priorizar tareas y fijar un tiempo máximo para las menos importantes adoptando una decisión en caso necesario.
2y3) Calidad, calidad y calidad. Toda metodología de gestión de proyectos incluye controlar la calidad de los productos (intermedios y finales) que se generan en el proyecto. Si el jefe de proyecto hubiera asignado a una persona que comprobara el etiquetado de pescados y a una segunda que comprobara los precios (evidentemente distintas de las que lo hicieron originalmente) los problemas se hubieran reducido.
4) Independiéntemente de quién comete un error, como jefe de proyecto eres el responsable último ya que tú asignaste dicha tarea. Si hubieras hecho 2y3) no te encontrarías en esta situación. En un programa como "The Apprentice" buscas que la gente sepa quién es el que comete los errores para encontrar un cabeza de turco, pero un jefe medio despierto es capaz de leer entre líneas, así que con todo eso sólo provocas división en tu equipo sin ningún beneficio para ti (el jefe de proyecto ya tiene enemigos para las próximas semanas). Siempre hay que buscar soluciones y no responsables, lo que no quiere decir que no debamos aprender de nuestros errores.
Del equipo ganador no hablo, aunque cometió casi más errores que el perdedor, con falta de liderazgo, sin repartir responsabilidades, sin poner precios fijos por el pescado, sin comprobar la competencia ...
Las reglas de la gestión
Cuando dejé mi anterior empresa (IT Innovation) para mudarme a la zona de Londres (Old Hatfield), mi jefes y compañeros, como es tradición, decidieron hacerme unos cuantos regalos. Entre ellos se encuentra un libro llamado "The Rules of Management" de Richard Templar que comenta 100 reglas para la gestión, ya sea para la dirección de un equipo (34 de ellas) o para gestionarse a uno mismo (el resto).Es una lectura interesante. Como todos los libros de este tipo, lo que cuenta es 90% sentido común (el menos común de los sentidos). Sin embargo, es interesante hacer un ejercicio y valorar cuántas de todas esas reglas estamos realmente aplicando en nuestro día a día. En conclusión, un buen libro de referencia para valorar y pulir nuestras habilidades como managers.
martes, 1 de abril de 2008
Introducción a Prince2
Este viernes hice el examen de Prince2 Practicioner, una metodología para la gestión de proyectos a lo largo de todo su ciclo de vida. Los resultados estarán dentro de un mes, así que toca esperar.
Desde mi punto de vista, lo más importante en relación a este tipo de metodologías es que uno ha de ser capaz de adaptarlas en cada proyecto, equilibrando la flexibilidad con el control (Prince2 habla de 'tayloring').
Otro aspecto a tener en cuenta es que una buena metodología no hace a un buen director de proyectos ni implica conseguir un proyecto exitoso. Es necesario adaptarla y aplicarla de forma correcta. Un ejemplo es la Terminal 5 de Heathrow. En estos casos uno no sabe si el proyecto se ha ido de las manos o si, simplemente, se conocía la existencia de un riesgo y decidieron que el impacto y la probabilidad de ocurrencia eran asumibles o no compensaban el coste de las contramedidas necesarias.
En los periódicos españoles se hace leña del árbol caído olvidando problemas pasados con la T-4 (por ejemplo 1), si bien fueron menores que los ocurridos en Heathrow.
Desde mi punto de vista, lo más importante en relación a este tipo de metodologías es que uno ha de ser capaz de adaptarlas en cada proyecto, equilibrando la flexibilidad con el control (Prince2 habla de 'tayloring').
Otro aspecto a tener en cuenta es que una buena metodología no hace a un buen director de proyectos ni implica conseguir un proyecto exitoso. Es necesario adaptarla y aplicarla de forma correcta. Un ejemplo es la Terminal 5 de Heathrow. En estos casos uno no sabe si el proyecto se ha ido de las manos o si, simplemente, se conocía la existencia de un riesgo y decidieron que el impacto y la probabilidad de ocurrencia eran asumibles o no compensaban el coste de las contramedidas necesarias.
En los periódicos españoles se hace leña del árbol caído olvidando problemas pasados con la T-4 (por ejemplo 1), si bien fueron menores que los ocurridos en Heathrow.
Arquitectura empresarial (Enterprise Architecture)
¿Qué es la arquitectura empresarial y por qué es importante?
Parafraseando a la Wikipedia "es la descripción de la estructura y comportamiento presente y futuro de los procesos, sistemas de información, personal y subunidades de una organización, alineados con la dirección estratégica y los objetivos principales de la organización".
La clave de esta definición se encuentra al final de la misma. Todos los elementos que forman una organización han de remar hacia la misma orilla, es decir, debe existir una relación identificada entre cada uno de esos elementos y lo que aportan a los objetivos estratégicos de la organización.
Una combinación de metodologías como Zachman y TOGAF facilitarán sin duda conseguir esos objetivos. En futuras entradas trataré de analizar lo que aporta cada uno de estos marcos de trabajo.
Parafraseando a la Wikipedia "es la descripción de la estructura y comportamiento presente y futuro de los procesos, sistemas de información, personal y subunidades de una organización, alineados con la dirección estratégica y los objetivos principales de la organización".
La clave de esta definición se encuentra al final de la misma. Todos los elementos que forman una organización han de remar hacia la misma orilla, es decir, debe existir una relación identificada entre cada uno de esos elementos y lo que aportan a los objetivos estratégicos de la organización.
Una combinación de metodologías como Zachman y TOGAF facilitarán sin duda conseguir esos objetivos. En futuras entradas trataré de analizar lo que aporta cada uno de estos marcos de trabajo.
Suscribirse a:
Entradas (Atom)