Me ha gustado mucho el trabajo de Stephen Wilkes, para la revista Fortune, tanto este time lapse como las fotografías.

Wal-mart es la mayor compañía del mundo por volumen de facturación, y también el mayor empleador y minorista. Son los más grandes, pero sólo pueden sobrevivir siendo los más grandes, creciendo, acelerando. Cuando han tenido que pelear en un entorno en el que no lo eran, como en Alemania, se han retirado derrotados. Necesitan que el tráfico de norteamericanos de clase media-baja acudiendo a sus tiendas no pare. Ahora tienen un problema: la propia compañía achaca la caída en las ventas del último período de facturación – entre otros – al hecho de que sus clientes tienen problemas para pagar la gasolina para llegar a Wal-Mart.

Esa clase media-baja que han ayudado a colocar en una situación insostenible con deslocaciones de producción, una competencia insalvable para el pequeño comercio y una necesidad parcialmente inducida de consumo irresponsable puede llevarlos ahora a una situación insostenible. Sería un precioso ejemplo de equilibrio cósmico, podría llegar a sacar una sonrisa, si no fuera porque al final quien sufriría la hipotética quiebra no sería el tiburón que maneja la compañía desde Bentonville, si no el cajero a media jornada de Wichita.

Hoy, desde mi suprema ignorancia y soberbia (siempre bien ligadas) voy a postular mi primera afirmación lógica. Si la Primera Ley de Parkinson¹ afirma que:

El trabajo se expande hasta llenar el tiempo de que se dispone para su realización.

Yo propongo como primer corolario para esta ley:

Siendo t₀ el momento de inicio del trabajo, existirá un momento t_n a partir del cual la relación entre el tiempo transcurrido y tiempo necesario para terminar el trabajo se mostrará de manera asintótica, no siendo posible finalizar el trabajo jamás.

Esto es aplicable a proyectos de diseño, pero también a limpiezas, mudanzas o toma de decisiones en el campo de las compras de moda.

1. Las Tres Leyes de Parkinson fueron descritas por el historiador británico Cyril Northcote Parkinson en 1957 en su libro La Ley de Parkinson y otros estudios. Estas leyes, crítica irónica de la burocracia, están basadas no sólo en la sorna de su autor, si no en la observación del comportamiento del funcionariado del Servicio Civil Británico. Más info en Wikipedia.

Hoy va de generalidades.

Sección I, Estructura de la Gestión de Proyectos.
Capítulo 2, El contexto de la Gestión de Proyectos

Para un equipo de diseño el empleo de las técnicas de la gestión de proyectos debe aportar orden, certeza y seguridad. A mi modo de ver, junto a una clara y compartida definición del alcance, la planificación de las fases del proyecto es la mayor motivación para adoptar estas herramientas en el mundo del diseño. De esta manera se establece el ciclo de vida del proyecto, lo que es el comienzo no sólo para marcar tareas a lo largo del tiempo, si no además quién participará en ellas, los recursos necesarios o qué información debe ser comunicada en cada momento. Es la base.

La planificación de las fases debe entenderse como una estratificación: cada estrato se define por la interfase entre él y los que lo separan. Esta interfase será cada entrega, cada cambio de proceso, cada aprobación. Comúnmente, a este momento se le llama hito, y al cambio de estado del proyecto que hace que exista un hito se le llama prestación. No tiene sentido marcar un número exagerado de hitos en la planificación del ciclo de vida de un proyecto de diseño, esto puede afectar negativamente al trabajo de los diseñadores, con cambios de rumbo cuando se encuentran trabajando. El diseño es iterativo; y romper el proceso abductivo será contraproducente. Es importante ver resultados y que estos se presenten en tiempo. Pero no es tan importante que cada semana haya una revisión.

Los hitos no deben ser vistos únicamente como una meta volante a la que se ha llegado olvidando el camino recorrido y con la vista puesta en la siguiente meta. Deben servir como puntos de reflexión en los que se evalúe el proceso y el resultado, es el momento de hacerse preguntas. En caso de que sea necesario deben ser también puntos de inflexión en los que aplicar las medidas necesarias para que el proyecto llegue a buen fin.

Son pocos (o ninguno…) los proyectos desarrollados de una manera completamente lineal en los que una fase no comienza si no se ha terminado la anterior. Lo más normal es que las fases discurran con solapamientos o con tramos en paralelo. Los solapamientos tienen un cierto riesgo que hay que considerar, ya que permiten que comencemos la fase X sin haber terminado la Y. Seguro que necesitaremos información proveniente de Y para completar X, y si existen cambios cuando la segunda fase ya ha comenzado lo que parecía una manera de ganar tiempo puede convertirse en un derroche de esfuerzos. Además no conoceremos el resultado de la evaluación del proceso que tantos beneficios puede traer.

Un ejemplo muy sencillo. La fase III de un proyecto consiste en el modelado mecánico de un equipo de maquinaria industrial, la fase IV preparará los planos. Cuando las primeras piezas están modeladas puede ganarse tiempo haciendo sus planos. Sin embargo esto puede ser una pérdida de tiempo si en el ensamble del conjunto se encuentran problemas en una pieza y esta debe ser rediseñada. Avanzar empleando el fast tracking¹ puede hacernos ganar tiempo, pero el riesgo debe estar siempre bajo control.

Hay infinitas maneras de llamar a las fases, y no todos los proyectos tendrán las mismas. Es muy fácil justificar una estructura en un manual y venderla como la más adecuada, pero lo importante no es definir si la conceptualización es parte del anteproyecto, o si los testeos forman parte del desarrollo del producto. Lo importante es que la estructura esté interiorizada y sea muy fácil de entender. Esto es lo que ayudará a que seamos capaces de distinguir dónde comienza una fase y termina la siguiente, en qué tarea y con que requerimientos. Permitirá además flexibilizarla o adaptarla a distintos proyectos.

Cada manera de presentar el ciclo de vida del proyecto se va a adecuar a las necesidades de un tipo de proyecto concreto. Sin embargo, para el campo del diseño yo crearía un diagrama de Gantt² muy simple acompañado por una hoja de tareas. ¿Por qué? El diagrama de Gantt es un clásico, casi un estándar, cualquier programa de gestión de proyectos lo emplea como base, es muy fácil extraer la ruta crítica a partir de él y, sobre todo, es extremadamente fácil de leer. Es visual y es muy sencillo aprender su lenguaje. Si lo acompañamos de una hoja de tareas en texto exponiendo en qué consiste cada tarea, quién la desarrollará, la información necesaria como imput y la información exigida como output, cualquier miembro del equipo puede tener acceso a un montón de información de un modo muy sencillo y sin necesidad de recibir formación sobre el tema. Se trata de ganar tiempo y seguridad, no de perderlos.

Hay también muchas maneras de llamar a aquellos a los que afecta el proyecto: stakeholders, clientes, usuarios… Cada nombre tiene sus matices, pero no es mi objetivo teorizar sobre esto. Lo importante es ser consciente de qué personas, grupos y organizaciones se van a ver afectados por el proyecto y su resultado y cómo serán afectados. Posiblemente el punto más peliagudo sea controlar las expectativas de todos, mantenerlas dentro de la realidad y en la misma dirección. En mi humilde opinión, ante un conflicto de intereses el usuario debe ser el que salga ganando, así ganará el producto y finalmente el cliente. Esto es muy simple pero hace falta recordarlo.

La gestión de proyectos no es una atalaya desde la que se controle el desarrollo del diseño, está en contacto y bajo la influencia de muchas otras actividades. El PMBOK describe las características de aquel que debe tener las responsabilidades de PM dentro del equipo de diseño: liderazgo, capacidad de comunicación, habilidades de negociación y solución de problemas, tener un espíritu inspirador… Dejando a un lado las apreciaciones personales, todas estas características son ciertas y deseadas, pero en la mayor parte de los casos, lamentablemente, el gestor de proyectos será el diseñador con más años o uno de los socios de la empresa, sin tener en cuenta que cumpla con estos requerimientos o que tenga conocimientos sobre gestión de proyectos. Esto es algo que debe cambiar.

Bonus: Video del Maestro Herbert von Karajan en un ensayo. Muchas veces he oído que el project manager tiene que ser un director de orquesta, capaz de tocar todos los instrumentos, que debe saberse la partitura de memoria y motivar a todos los los miembros de la orquesta. Creo que es bueno quitar a todo esto un poco (bastante) de importancia. Por favor, que cada Karajan que nazca se convierta en director de orquesta, que no se le ocurra gestionar proyectos.

Esta entrada forma parte de un conjunto de anotaciones sobre las técnicas y herramientas descritas en el PMBOK del PMI para la gestión de proyectos, enfocadas a la gestión de proyectos de diseño.

1. Fast tracking es el nombre que se da a los solapamientos en fases o tareas. Consiste en poner a trabajar en paralalo procesos que en otro caso discurrían uno tras otro, siendo los outputs del primero los imputs del segundo.
2. El diagrama de Gantt es una representación gráfica sobre unos ejes ortogonales de las tareas de un proyecto frente al tiempo y de sus interacciones.

Me voy de Barcelona. Es un cambio de aires que necesito y confío que me vendrá muy bien. No quiero hacer de esta entrada una recapitulación de nostalgias por llegar – que llegarán – pero sí quiero decir que los últimos veinte meses han sido increíbles. Me voy para que los próximos también lo sean. Gracias a todos, gracias Barcelona.

Rompo con la norma en este post emo y, aunque sea de espaldas, el de la lomografía de la entrada soy yo. La sacó Dani en una buena tarde que pasé con él y con Marta, quien confío que llore con Christian y conmigo cuando finalmente me vaya.

Al turrón

Sección I, Estructura de la Gestión de Proyectos.
Capítulo 1, Introducción

El PMBOK comienza definiendo qué es un proyecto, y lo hace contraponiéndolo a la otra manera de ejecutar el trabajo, las operaciones. Simplificando, los proyectos se desarrollarán una vez, durante un tiempo determinado, mientras que las operaciones se desarrollan repetidas veces a lo largo del tiempo. La búsqueda de clientes por parte del equipo comercial de un estudio puede ser una operación, desarrollar un nuevo producto para uno de ellos un proyecto: existirá un único resultado – un modelo 3D, un fichero .ai, unos planos – y se desarrollará a lo largo de un período de tiempo limitado.

Profundizo un poco más en la idea de temporal. Esto significa que todo proyecto tendrá un inicio, un desarrollo y un final. ¿Cuándo llega este final? La respuesta parece sencilla: cuando se entregue al cliente. Esto no es necesariamente así, porque habrá casos en que se detecte la imposibilidad de resolver el problema o el proyecto se enfríe. Esta última es la peor de las situaciones, ya que deja el proyecto en el limbo y seguramente una relación enrarecida entre el equipo de diseño y el cliente. La temporalidad se refiere sólo al proyecto, no al producto. A Dieter Rams le tomó un tiempo determinado crear el Shelving System 606, pero hoy día Vitsœ sigue vendiéndolo y el público apreciándolo.

Es muy complicado delimitar más qué es un proyecto genéricamente, ya que su estructura, duración, fuerza de trabajo o forma legal son totalmente variables, y no harán otra cosa que ajustarse a las necesidades en cada caso. Muchas veces los proyectos forman parte de una jerarquía estratégica: programa > proyecto > subproyecto. Esto puede afectar al equipo de diseño de dos maneras. La primera es si tiene la suerte de influir en el programa, afectando la línea estratégica de la empresa. La segunda, quizá menos afortunada, es cuando tiene que trabajar bajo los requerimientos de un programa definido por otros que pueda encorsetar su trabajo.

El concepto probablemente más interesante a introducir en este punto es el de alcance. El alcance es aquello que queremos conseguir, y en ocasiones incluso cómo queremos conseguirlo. Para el mundo del diseño debemos contemplar tanto el alcance del proyecto como el alcance del producto. El alcance del proyecto es sencillamente qué objetivo tiene el proyecto: “un conjunto de archivos IGES con la carcasa de una aspiradora de mano e indicaciones previas para la inyección en plástico“. Debe definirse desde el principio, puede tener variaciones, pero estas deben ser más depuraciones que evoluciones. Debe mantenerse bajo control y ser reconocido por diseñador y cliente.

El alcance del producto es un concepto completamente distinto. Es el resultado, no el objetivo. La respuesta al problema “carcasa de aspiradora de mano en formato IGES” puede tener infinitas soluciones posibles. Si el alcance del proyecto debe estar controlado dentro de unos límites, el alcance del producto tiene una sanísima incerteza. Por muy planificado que esté el proceso, por muchos exámenes, modelos, datos y experiencias pasadas que se hayan analizado, las soluciones se conseguirán de un modo más o menos iterativo, más o menos progresivo. Nos acercaremos con el tiempo y el trabajo. El propio avance del proyecto lo definirá más y más. La gestión de proyectos aporta certezas desde el momento del planteamiento, pero esta mayor seguridad no borra las incertidumbres naturales del diseño. Es muy sencillo: al diseñar se crea algo nuevo, y por tanto algo con aspectos desconocidos que no es posible controlar por completo. El resultado es predecible, pero no anticipable.

Algo a tener en cuenta: no siempre se puede culpar al cliente de los cambios en el alcance. Los diseñadores también se alejan del brief en busca de la innovación, de conseguir un mejor producto o mayor repercusión. Además las responsabilidades en un proyecto son compartidas. Siempre. Incluso cuando el cliente intenta salirse del camino planteado es responsabilidad de quien gestione el proyecto desde el equipo de diseño recordarle la ruta.

Los campos de intersección entre las responsabilidades funcionales de la gestión tradicional y la gestión de proyectos son múltiples, yendo desde la selección de personal a la gestión de la información. Los equipos de diseño, sobre todo aquellas estructuras más reducidas, están muy acostumbrados a manejar muchas responsabilidades ajenas al diseño, a realizar labores comerciales o de comunicación y suelen ser muy flexibles.

Creo que es muy interesante aclarar que las técnicas que describe el PMBOK o cualquier otra filosofía de gestión de proyectos no son herramientas de productividad personal del estilo de GTD. Estas herramientas, muy populares actualmente, ayudan a ser más productivo en el día a día, a sentirse mejor con el trabajo realizado, a mantener el estrés bajo, y estoy seguro de que son complementarios, pero en ningún caso sustitutivos. Estas herramientas tienen un campo de actuación distinto que se extiende hasta las operaciones, pero no sirven para planificar el diseño de una nueva lámpara aunque ayuden a que aquellos encargados de modelar sus piezas a cumplir con las tareas asignadas dentro de una fase concreta en el tiempo y forma debidos.

Bonus: El vídeo de 2′ 52” que acompaña a esta entrada es un triple bonus. Se trata de Mark Adams, Director de Vitsœ, hablando sobre la atemporalidad del resultado de los proyectos temporales que desarrollan. En cristiano, de la sana pervivencia de sus productos. Solo una cita, que daría para muchas entradas:

The concept is to reuse your furniture… We see recycling as a defeat.

Esta entrada forma parte de un conjunto de anotaciones sobre las técnicas y herramientas descritas en el PMBOK del PMI para la gestión de proyectos, enfocadas a la gestión de proyectos de diseño.

He leído últimamente a varios desarrolladores de aplicaciones para el iPad hablar sobre los excesos de Apple a la hora de intentar llevar a su interfaz metáforas visuales del mundo real creando un 3D falsamente realista No es nada nuevo, pero creo que hay un salto entre el uso de un disco de 3 1/2″ como icono de guardado y la estantería de Delicious Library. Ahora parece que se ha exagerado con las directrices que da Apple para la creación de interfaces para el iPad, directrices que son ya tendencia y pronto serán norma en el mercado.

Me vienen varias razones a la cabeza por las que Apple puede haber hecho esto. Quizá sea la manera de tradicionalizar un aparato rompedor. Por hacerlo más mono. Por demostrar una atención al detalle llevada al extremo. O por crear una nueva línea visual que haga viejo lo existente y genere necesidad en el mercado. Habrá un poco de todo, pero parece que la razón ha sido la intención de hacerlo más intuitivo, más reconocible. Esto se hace difícil de justificar. Como ejemplo, algo que expone Information Architects: no es fácil entender cuánto de intuitivo tiene hacer scroll vertical en una página que imita papel y se navega lateralmente pasando páginas como un libro.

Más allá de esto, formalmente muestra la tendencia a un sobrediseño clasicista en el mundo digital, una especie de tecno-neo-barroco-raro, muchas veces prescindible y poco adecuado. Hay miles de ejemplos y la frontera entre lo molón y el kitsch está muy difusa.

Sin embargo no dudo de que esto no está limitando la posibilidad de crear un lenguaje nacido del mundo digital, eso es imposible. Simplemente forma parte del mainstream más mainstream. Gustará más o menos, pero se encuentra influido por todo lo que lo rodea y esto incluye las tendencias más clasicistas y reaccionarias.

El video es de CODECO, uno de sus iconos materializados, un disco de 3 1/2″ en punto de cruz sobre una camiseta. Es el proceso revertido.

Bonus: El corrector ortográfico de Mac OS cambia iPad por piad.

British architect Kenneth Allinson discussed in his book Getting There by Design factors that affect the perceived success of a project. (…) They are:

1. Coordination and human relations
2. Budget, schedule, and technical performance
3. Project conceptual difficulties
4. Project organizational structure and management controls
5. Project budgetary constraints
6. Project importance and public exposure
7. Team capabilities

Surprising as it may sound, Baker’s finding show that factor one, coordination and human relations was significantly the most important of the seven: “Co-ordination and relations: Team spirit, unity, human relations skills, enthusiasms, participation, etc. This factor is about four times as important as the seventh factor and about 50% more important than the second factor”.

Project Management fot Design Professionals
William G. Ramroth J

Traduciendo libremente:

El arquitecto británico Kenneth Allinson trata en su libro Getting There by Design los factores que afectan al éxito percibido de un proyecto. Estos son:

1. Coordinación y relaciones humanas
2. Presupuesto, plazos y ejecución técnica
3. Dificultades conceptuales del proyecto
4. Control de la gestión y estructura organizativa del proyecto
5. Limitaciones presupuestarias del proyecto
6. Importancia y relevancia del proyecto
7. Capacidades del equipo

Por muy sorprendente que parezca, las conclusiones de Baker muestran que el primer factor, coordinación y relaciones humanas era de largo el más importante de los siete: “Coordinación y relaciones: Espíritu de equipo, unidad, habilidades sociales, entusiasmo, participación, etc. Este factor es hasta cuatro veces más importante que el último y un 50% más importante que el segundo”.

Las sensaciones derivadas de las relaciones sociales son hasta un 50% más importantes para el éxito percibido de un proyecto que su ejecución, el cumplimiento de los plazos y el presupuesto. Puede parecer increíble, pero si confiamos en los estudios es la realidad. La realidad en el mundo anglosajón, ¿cómo estará el tema por aquí, entre los pasionales mediterráneos?

Sabiendo lo importantísima que es la confianza, y olvidando lo desesperanzador que puede ser para algunos que el reconocimiento de su trabajo dependa de sus habilidades sociales, la mejor conclusión que se debe sacar de esto es que tener un buen cliente es tener un buen proyecto.

Me ha encantado esta infografía de Kenichi Tanaka. Primero porque expone una serie de datos obetivos que intentan subjetivar la situación de la cultura y sobre todo sociedad japonesa, algunas veces denostada, muchas otras sobrevalorada. No hay sociedades buenas ni malas. Algunas hacen las cosas mejor o peor en un campo o momento determinado pero, lamentablemente, flaquean por otro lado. Lo importante es, como siempre, el equilibrio.

En segundo lugar me ha gustado por la manera en que lo ha hecho, con una imagen lúdica, llena de color y humor. Establece un lenguaje sencillo que se complementa a la perfección con un discurso complejo de datos y apreciaciones encadenadas.

Por último, no puedo parar de pensar en poner este video el lunes en el estudio y ver la reacción de la mitad de mis compañeros de trabajo, japoneses. Creo que no es habitual para su cultura hacer este tipo de autocríticas sobre Japón en voz alta. Tanto es así que en la descripción del vídeo en su cuenta de Vimeo – también me ha gustado la animación sobre el dopping – Kenichi pide que nadie lo tilde de racista, recordando que él mismo es japonés.

Actualización a 31 de marzo: Kenichi ha retirado la versión en inglés. Prefiero no preguntarme porqué. He insertado el original en japonés porque creo que la parte gráfica está tan bien hecha que una buena parte del contenido sigue siendo entendible.

Soy, por formación, diseñador industrial. Estudié lo que hasta hace poco se llamaba Ingeniería Técnica en Diseño Industrial. Durante la carrera llevamos a cabo un buen número de proyectos, también durante el Master de Diseño de producto que hice después. Comencé a trabajar en un estudio y seguí participando en la gestión y soporte de proyectos de diseño.

En un momento, estando aún en la carrera, me di cuenta de que los proyectos seguían una metodología, más o menos acertada, pero había carencias a nivel de guía proyectual. Se notaba una falta de control sobre el resultado desde el comienzo (alcance…), sobre la duración e interrelacion de las fases (el tiempo…), y sobre la estimación de esfuerzos de trabajo y materiales requeridos (el presupuesto…). Fue en ese momento en el que me interesé por la gestión de proyectos buscando una herramienta que, cobarde de mi, permitiera tener las cosas bajo mayor control. Aquí llega la primera pregunta, ¿qué es la gestión de proyectos?

La gestión de proyectos es la disciplina de organizar y administrar recursos de manera tal que se pueda culminar todo el trabajo requerido en el proyecto dentro del alcance, el tiempo, y coste definidos.

Esta definición extraída de Wikipedia que casa perfectamente con la dada por el PMI¹ limita la actuación de los gestores de proyectos – simplificando – a que un proyecto cumpla lo que debe ser, en el tiempo que debe, con el presupuesto que debe. Segunda pregunta entonces, ¿quién es el gestor de proyectos? Citando una vez más Wikipedia:

Un gestor de proyecto (…) es la persona que tiene la responsabilidad total del planeamiento y la ejecución acertados de cualquier proyecto.

Surge una pregunta lateral, ¿es lo mismo la figura del gestor de proyectos que la del project manager? La respuesta parece sencilla, ya que es sólo una traducción del inglés al español, pero no es así. En la práctica, un gestor de proyectos es siempre un project manager, aunque hoy un project manager no es siempre un gestor de proyectos. Es muy frecuente que se emplee el término project manager para denominar a un coordinador de un área funcional, un comercial con perfil técnico, un responsable de un grupo de trabajo, el gerente de una oficina, un gerente de producto… por ejemplo, buscando project manager en las ofertas de empleo de portales como Infojobs o Monster, se pueden encontrar muchas más de comercial que de gestor de proyectos. Es una lástima que una profesión con tanto potencial pierda parte de su valor, al menos simbólico, al ser usado su nombre para vestir – o disfrazar – otras.

Hasta ahora tenemos una disciplina, la gestión de proyectos, una profesión, la del gestor de proyectos. ¿Y el campo de actuación? Enorme: la construcción, la investigación científica, los servicios, el mundo militar, la administración, cualquier área que pueda atender su actividad en base a proyectos puede obtener beneficios de gestionar su planteamiento y ejecución. Sin embargo existen dudas sobre su aplicación al mundo creativo, al diseño (producto, comunicación o espacio). Estas dudas son a veces bien fundadas, porque algunas estructuras son incapaces de seguir un control proyectual con aires mecanicistas, porque en algunas ocasiones los intentos por establecerlo pueden crear más problemas de los que solucionan y porque, con muchísima frecuencia, las estructuras son tan reducidas e informales que simplemente la aplicación de la gestión de proyectos sacada del manual cual dogma no tiene sentido. Xènia Viladàs escribe:

En las pequeñas empresas (la gestión del día a día del proyecto) se hará informalmente, a medida que se van desarrollando las etapas y no será objeto de grandes procedimientos, mientras que en las empresas certificadas se seguirán los protocolos establecidos.

Diseño rentable, diez temas a debate
Xènia Viladàs, Ed. Index Books

Sin embargo, las técnicas y herramientas de la gestión de proyectos pueden ser adaptadas de modo que aporten valor al resultado, solidez a la organización y un apoyo más a los miembros del equipo encargado del diseño. Esta es mi premisa, me lo creo. Una última pregunta – por ahora – ¿cómo lo hacemos? Propongo tomar el PMBOK², la biblia del Project Management con todos sus pros y contras y revisarla de principio a fin buscando vincularla con el diseño. La razón de haber elegido este manual es, aparte del valor de su contenido, el hecho de que signifique un estándar en la industria. Empiezo una serie de entradas en las que haré algo parecido a una lectura comentada sobre el tema. El resultado será un documento en evolución, me encantaría que participativo, abierto a todo aquel que lo encuentre útil de algún modo.

Como bonus algo diferente: un punto de vista de cómo en diseño puede ayudar a dar valor a la gestión de proyectos en un artículo de Douglas R. Parker para Design Inteligence. Una lectura esperanzadora y muy recomendable. Como segundo bonus, la imagen que encabeza esta entrada, obra de Ben Barry extraída de Simple Desktops.

1. El PMI o Project Management Institute es una organización sin ánimo de lucro que se ha erigido como la asociación profesional creadora de estándares en el mundo de la gestión de proyectos. No sólo sus documentos son seguidos de manera generalizada, si no que sus exámenes se consideran capacitadores para ejercer la gestión de proyectos.
2. El PMBOK o Project Management Body of Knowledge se recoge en A Guide to the Project Management Body of Knowledge, un manual editado por el PMI, que sirve de guía de los fundamentos de la gestión del diseño y de libro de texto para sus certificaciones.

And now for something completely different es la frase con la que John Cleese daba inicio al programa de la BBC Monty Python Flying Circus. Cada vez que la oigo sé que voy a pasar un buen rato riendo y sonriendo. Los estoy revisitando desde hace unas semanas y, sin lugar a dudas, ver uno de sus episodios es la mejor manera de acabar el día.

Bonus: Además de ser unos genios del humor y la televisión, son unos tíos despiertos. Cuando se dieron cuenta de que la gente subía sus vídeos a Youtube, abrieron un canal, lo llenaron de contenido, y establecieron una relación muy positiva con un público deseoso de conseguir más material. Finalmente, esta maniobra les salió muy rentable no sólo en términos de imagen, si no también económicamente. El anuncio que usaron es simplemente genial.