Actualizaciones y comentarios breves

Gente, algunas actualizaciones sobre temas relacionados con el interés de los miembros del grupo Mejoras de procesos de TI  en Linkedin y comentarios breves van por twitter en @RaulMartinez582

saludos,
Raúl

Desarrollar software hoy

Desarrollar software hoy. Sólo controlamos lo encerrado en el círculo.
Partes tomadas de bi-modal IT del Gartner Group.


Raúl Martínez‏@RaulMartinez582

La Persona detrás de El Usuario

Al tratar de entender un problema a resolver o la solución a proponer, hablamos habitualmente de El Usuario. Eso es correcto según toda la literatura y es quien en última instancia utilizará nuestro producto/servicio.  

Bastante tiempo atrás nos preocupaba que este usuario recibiera un producto funcionalmente correcto, luego en la medida que la tecnología lo permitió sumamos cada vez más la idea de usabilidad y finalmente hoy debemos sumar algo más abstracto de definir que es la persona que está detrás de ese usuario.

Así como la propuesta Ágil nos muestra, entre varias otras cosas, la Persona que está detrás del Recurso en el Equipo de Trabajo y lo útil que es considerarla, deberíamos examinar cómo nuestro modelo de análisis de los problemas contemplan a la persona detrás del usuario y no sólo la funcionalidad que utilizará en la operación del producto.

Hay varios factores además del funcional, como el social o el emocional, que pueden finalmente transformarse en requerimientos tal como cualquier otro requerimiento funcional que conocemos.

En mi opinión este tipo de análisis es un movimiento imparable debido a la presión y difusión de las tecnologías que hoy ya están totalmente incorporadas al plano social y personal.

Sobre el tema, hay literatura interesante que si bien pertenece a lo que llamaríamos habitualmente libros de negocios, creo que son necesarios para el analista de negocios, el product manager , el arquitecto / desarrollador senior y por supuesto el emprendedor.

Los libros son estos:

--Business Model Generation, Osterwalder, Pigneur, 2009

--Value Proposition Design, Osterwalder, Pigneur , Bernarda, 2014

--The four steps to epiphany. Steve Blank, 2013

--The Startup Owner’s Manual. Blank , Dorf, 2012

Ninguno trae ideas revolucionarias, excepto el formato gráfico de los dos primeros utilizado para plantear temas áridos de negocios. Hay ideas de Christensen, Kim, Ries, etc. Bien condensadas y presentadas.

Conviene empezar por el primero Business Model.

Hay que tomarse un tiempo para leerlos, desprenderse del preconcepto de “eso es un  tema del negocio, no mío” y recordar siempre la frase de Steve Blank  -- get “outside of the building” -- que las cosas ocurren fuera de nuestro lugar de trabajo. Con la lectura no basta.

Hasta la próxima.

Raúl Martínez

rmartinez@rmya.com.ar

www.rmya.com.ar / Ideas sobre el software / Twitter: @RaulMartinez582

Interés de los lectores

Distribución del interés de los lectores de nuestro blog ideassobresoftware.blogspot.com.ar, en los distintos temas a lo largo de los meses. Estos son los 10 primeros puestos en cantidad de lecturas.

Entrada	Fecha de Publicación	Tema
Calidad no es testing, ni procesos, ni certificaciones	Oct 2013	Calidad de producto y expectativas
¿Encajar una pieza cuadrada en un hueco redondo? E...	Jun 2013	Administración de proyectos
Acercarnos al Negocio (Conclusión)	Nov 2013	Calidad y negocios, el resumen
Indicadores accionables	Jun 2013	Indicadores Negocio/Producto
¿Todavía quiere seguir jugando?	Sep 2013	Complejidad de distintos escenarios
Sobre Pruebas de software y Servicios de TI	Aug 2013	Testing y servicios
Sobre nuestra misión como testers	Jul 2013	Testing
ISO 25000 y otras - Calidad en Uso	May 2013	Calidad de producto
Release or not release, that is the question!	Sep 2013	Calidad de producto y negocio
La Calidad (no?) se negocia	May 2013	Calidad de producto y negocio

Saludos,

Raúl

TW: @RaulMartinez582

¿Todavía quiere seguir jugando?

Una pequeña historia

Entramos a un Casino en el que hay diferentes juegos en los que podemos elegir apostar. En una mesa hay un juego llamado “Multimedia”, en otra uno llamado “Web-services”,  en otra uno llamado “Banca Electrónica”.

Nos acercamos al crupier y se desarrolla el siguiente dialogo:

• Nosotros: “Cuánto la apuesta mínima?”
• Crupier: “3000 millones”
• Nosotros: “¿Quién jugará?”
• Crupier: “No lo sabremos hasta que lleguen”
• Nosotros: “¿Cuáles son las reglas?”
• Crupier: “Aparecerán a medida que el juego avance”
• Nosotros: “¿Cuál es mi chance de ganar?”
• Crupier: “No podemos decirlo, ¿todavía quiere seguir jugando?”

¿Qué distingue a un gran líder de un líder promedio? Su habilidad para percibir la naturaleza y las reglas de un juego a medida que lo juega.(W. Brian Arthur)

--oo0oo-- 

El motivo de esta introducción es tratar de entender:

• ¿Cómo tomamos decisiones en un contexto cambiante e impredecible?
• ¿En qué podemos  basarnos?
• ¿Cómo podemos afirmarnos en un terreno resbaladizo como un problema poco definido y un entorno altamente cambiante?

Las preguntas son demasiado amplias, pero totalmente trasladables a gran cantidad de proyectos que encaramos en la actualidad con clientes más demandantes, competencia exacerbada, tecnología fluida, calidad sobreentendida, etc.

Los supuestos para la toma de decisiones

Nuestro sistema más común de toma de decisiones, está basado en

• Que existe en el contexto del problema un cierto grado de predictibilidad y orden,
• que se pueden hacer ciertas simplificaciones para entenderlo,
• y por lo tanto poder resolver situaciones que requieran decisión.

Esto cada vez es más difícil. El entorno de toma de decisiones es cada vez más cambiante y los supuestos antes mencionados no siempre, en realidad cada vez menos, se cumplen.

Dando sentido a las cosas

Una ayuda a estos problemas de decisión en contextos cambiantes podemos encontrarla en el concepto de “sensemaking”, cuya posible traducción sería “dar sentido”.

Sensemaking: es el intento de darle sentido a situaciones ambiguas, complejas o inciertas ayudando a tomar decisiones en ellas, tratando de entender las conexiones entre las partes intervinientes para anticiparse y actuar en forma efectiva.

Un marco de referencia para este “dar sentido”, lo propone el modelo Cynefin, de Kurtz y Snowden, al que ampliamos con las ideas de Snowden y Boone acerca de  la toma de decisiones utilizando esta propuesta.

Pero atención, los criterios que proponen no son una receta, sólo permiten razonar sobre posibles modos de encarar situaciones comunes en distintos contextos. Por ejemplo:

• Ordenados y simples
• Ordenados y complicados
• Desordenados y complejos
• Desordenados y caóticos

 Gráficamente

¿Cómo reconocemos cada entorno? ¿Cómo tomamos decisiones en cada uno? ¿Qué debemos resolver y qué problemas podemos encontrar?

Entorno Ordenado – Simple - Conocido

El dominio de las mejores prácticas (know-know).

¿Qué caracteriza a esta situación?

• Sucedió otras veces (repetible), es evidente, es predecible, si ocurrió un determinado evento sabemos lo que ocurrirá luego. Relación clara y lineal entre causa y efecto.
• El entorno es conocido y estable, la probabilidad de cambios es baja.
• Son aplicables las mejores prácticas, estructuradas en procesos.
• Habitualmente el conocimiento de la solución reside dentro de la misma Organización.

¿Qué debemos tener en cuenta para tomar una decisión en esta situación?

• Reconocer el contexto en el cual se desarrolla la situación.
• Detectar y evaluar la información que se recibe.
• Categorizarla.
• Responder de acuerdo a una práctica predeterminada.
• La “receta” es esencial ya que está probada y asegura repetibilidad.

¿Qué debemos lograr y fomentar?

• Mantener una comunicación directa y clara, no es necesario que sea excesiva; el tema es conocido y la solución también.

¿Qué problemas esperar y qué evitar?

• Equivocarse al leer el contexto y tratar de aplicar a todos los problemas las prácticas que conocemos. No poder pensar “fuera de la caja” para reconocer otra situación.
• Resistirnos a entender que el entorno cambió y las soluciones  anteriores ya no aplican.
• Confiarnos y simplificar demasiado; interpretar erróneamente lo simple como fácil.
• El síndrome “esto es lo mismo que antes pero dicho de otra manera”. Tal vez no es lo mismo, ni se le parece.       

Caso:

• Resolución de incidentes conocidos siguiendo pasos establecidos; no hay decisiones demasiado complejas y la mayoría de los casos están contemplados en “el manual”.

   

Entorno Ordenado - Complicado - Conocible

El dominio de la buena práctica o del experto -  (know-unknowns)

¿Qué caracteriza a esta situación?

• La cultura de la Organización, algún proceso establecido y seguido ya hace tiempo, la burocracia ya incorporada en las tareas, producen problemas no visibles desde dentro. La relación causa-efecto existe, pero no es reconocida por la Organización o fácilmente detectable por quien debe tomar la decisión.
• La causa puede estar separada del efecto, no es lineal (si toco aquí no explota allí inmediatamente) y posiblemente sólo un ojo entrenado y no comprometido,  pueda detectarla y aconsejar la decisión adecuada.
• Las causas y los efectos se centran alrededor de un tema, lo cual deja al tema todavía en el terreno de lo predecible. Por ejemplo re-trabajo, defectos, etc.
• Quien toma la decisión podría investigar, estudiar y finalmente también hacerlo, pero con tiempo e investigando. Asimismo ciertos conflictos de poder pueden actuar sobre una posible solución que descubra.

¿Qué debemos tener en cuenta para tomar una decisión en esta situación?

• Reconocer el contexto en el cual se desarrolla la situación.
• Detectar y evaluar la información que se recibe del contexto.
• Analizarla, posiblemente con ayuda.
• Responder de acuerdo a la sugerencia de el o los expertos.

¿Qué debemos lograr y fomentar?

• Coordinar e integrar opiniones diferentes entre los expertos.
• Crear una tema común de discusión evitando dispersión de los mismos expertos.
• Escuchar a los no expertos que podrían aportar una solución creativa.

¿Qué problemas esperar y qué evitar?

• Expertos demasiado confiados en su experiencia.
• Opiniones diversas (y contradictorias), intereses personales de los expertos.
• Parálisis por análisis.
• Expertos pensando sólo “dentro de su caja” sin considerar alternativas.
• Ignorar la solución propuesta, aunque sea evidente su corrección, por los problemas políticos que puede causar, sin analizar alternativas.

Caso:

• Una serie de síntomas típicos en una Instalación, re-trabajo, tiempos muertos, visibles para los expertos, pero que pasan desapercibidos para el resto, y que muestra la necesidad de una mejora en los procesos.

Entorno Desordenado – Complejo – Retrospectivamente comprensible 

El dominio de la exploración y el ensayo (unknow-unknowns)

¿Qué caracteriza a esta situación?

• La relación causa-efecto existe, pero la gran cantidad de variables intervinientes y relaciones entre ellas es tan amplia que no es posible incorporarlas en un proceso estructurado, ni analizarlas una a una ya que actúan a la vez. Por ejemplo proyectos extensos, con gran cantidad de personas intervinientes, organizaciones y tecnologías.
• Pueden buscarse patrones de comportamiento que, si se repiten, ayudarán a simplificar la detección futura de situaciones similares.
• La situación es entendible sólo retrospectivamente, es decir a posteriori, cuando se podrá encontrar una explicación para algunas de las cosas que sucedieron.         

¿Qué debemos tener en cuenta para tomar una decisión en esta situación?

• Como posiblemente estemos ante un caso único, como la mayoría de los proyectos donde nunca todas las variables se repiten aunque lo hagan algunas, habrá que explorar posibles caminos y experimentar en base a la información del resultado de nuestras acciones.
• Detectar patrones de comportamiento conocidos, e identificar nuevos. Responder de acuerdo a la nueva situación.        

¿Qué debemos lograr y fomentar?

• Propiciar la experimentación creando un ambiente adecuado.
• Lograr un alto grado de comunicación.
• Aceptar errores o fallas en los ensayos.

¿Qué problemas esperar y qué evitar?

• Incertidumbre en los resultados: estamos ante situaciones únicas.
• Asustarse con los resultados o la falta de ellos y reincidir en procedimientos estructurados, que sin duda fallarán ya que fueron pensados para otros entornos.
• Asociado a esto, perder la oportunidad de una solución creativa o alguna solución siquiera.
• Confusión entre experimento y caos.
• Buscar hechos concretos en un ambiente donde todo fluye y es difícil encontrarlos, en lugar de entender los patrones que van surgiendo.

Caso:

• Cualquier producto de cierta complejidad, tamaño, extensión, novedoso como idea, sobre tecnologías nuevas o en desarrollo, para mercados en expansión y variados. Productos originales o innovadores están en este entorno.
• Casos como YouTube, e-Bay, Google, las redes sociales, avanzaron en sus orígenes, y siguen actualmente, creando e identificando patrones de comportamiento que permiten cambiar el negocio a medida que se comprenden sus características.

·         

Entorno Desordenado – Caótico – Inesperado

El dominio de la respuesta rápida.

¿Qué caracteriza a esta situación?

• Es totalmente inesperada. ¡Pasó y hay que resolverlo!
• Nadie sabe exactamente qué hacer ya que escapa a todo lo conocido.
• Quién piensa en ese momento en detectar y analizar la relación causa-efecto: no hay tiempo.
• Lo primero es restablecer el orden, actuar rápidamente y detener la turbulencia.

¿Qué debemos tener en cuenta para tomar una decisión en esta situación?

• Actuar para volver a ordenarnos.
• Detectar el resultado de la acción y ver cuál puede ser el próximo paso. 
•  Responder de acuerdo al resultado, profundizar o cambiar por otra acción.

• No ir atrás de la respuesta correcta ni perfecta, sino de lo que funciona en ese momento.

¿Qué debemos lograr y fomentar?

• Actuar.
• Comunicar breve y claramente qué debe hacerse (órdenes en muchos casos).
• Impedir mayor caos.

¿Qué problemas esperar y qué evitar?

• Buscar culpables durante el caos: no ayuda a solucionarlo, al contrario.
• Actitudes tanto egoístas como altruistas de las personas.
• Continuar en la actitud de ordenar y controlar. Es útil para salir del caos, pero dañina más allá de lo necesario.
• Vivir en crisis; hay mejores formas de sentir la adrenalina.

Caso: 

• Situaciones de emergencia, caídas de los sistemas producidas por eventos fuera de cualquier riesgo esperado, aun los más extremos contemplados.

El centro: el desorden

¿Qué caracteriza a esta situación? 

• Conflictos entre quienes deciden.
• Ver la misma situación desde distintos puntos de vista.
• Competencia por interpretar la situación basados en sus preferencias. Unos tratan de aplicar el proceso, otros de experimentar, y otros de controlar.
• Cada uno lo llevará al plano donde cree tener más poder.

          ¿Qué debemos lograr y fomentar?

• Posiblemente la única solución es acercarlos y ayudar a que reduzcan sus diferencias.
• Buscar puntos en común.

• ...No es fácil...

Conclusión

La pregunta inicial fue cómo tomábamos decisiones en situaciones complejas o inciertas.

No siempre estamos (o deberíamos estar) en el plano de caótico, y hay gran cantidad de situaciones en el contexto de lo complicado y hasta de lo simple. No toda situación es una emergencia.

Habrá también casos de situaciones complejas, las cuales, a medida que las comprendamos deberíamos hacerlas transitar hacia los estadíos anteriores más ordenados y así lograr una forma repetitiva de resolverlas.

Los riesgos son varios y no sencillos de tratar ya que están relacionados con las personas, la cultura de la organización, el contexto donde se insertarán las soluciones, y podríamos seguir agregando. Aun así, el mayor riesgo es no hacer nada y tratar de aplicar la misma receta a todo, cualquiera sea esta receta y situación que estamos tratando.

Como agregado, y si bien implica también un riesgo, debemos visitar los contextos desordenados, ya que en muchos casos allí residen las ideas creativas, todavía no procesadas. Logradas nuevas ideas, nuevamente podemos tratar de volver a los contextos más ordenados.

Resumiendo y en palabras sencillas:

•        Simple = By the book
•        Complicado = Preguntar al experto
•        Complejo = Ensayar y analizar el resultado
•        Caótico = Actuar.

Material de referencia

• The new dynamics of strategy: Sense-making in a complex and complicated world, C. F. Kurtz y D. J. Snowden. IBM SYSTEMS JOURNAL, VOL 42, NO 3, 2003. Este trabajo dio origen al modelo. Es interesante, a veces necesita relectura.

• A Leader’s Framework for Decision Making, David J. Snowden y Mary E. Boone, Harvard Business Review • Nov. 2007. Toma los conceptos del trabajo original, y lo orienta más específicamente a quien toma decisiones. Muy interesante la tabla resumen con las características de cada contexto, sus acciones y sus riesgos.

• Increasing returns and the new world of business, W. Brian Arthur, HBR 1996.

• Definiciones de Karl E. Weick. Varias publicaciones.

La vieja y querida WBS

Al ser la creación de la WBS una práctica tan básica y con un resultado tan útil, es justo rendirle un pequeño tributo 
recordando su historia y algunos detalles de la misma. Tómese este post como ese sencillo tributo.

Si bien en la literatura de administración de proyectos prácticamente todo libro  tiene un apartado para el tema WBS, quiero recordar algunas publicaciones y algunos párrafos de autores que han escrito exclusivamente sobre ella:

1. El nombre de los componentes de la WBS ⁽¹⁾

El nombre de la WBS y sus componentes, sustantivos y no verbos. Este tema no es menor.

• Sustantivo - implica algo, un sistema, una casa, etc.
  
  Los niveles siguientes al nombre del proyecto, nos muestran un producto y cómo se va descomponiendo en sus partes.

• Verbo - implica proceso.
  
  Los niveles siguientes a un verbo nos muestran sus actividades y cómo se refinan.

Al Cliente posiblemente le interese más la primera visión, Sustantivo, ya que le resulta más sencillo “ver” los productos, que entender qué parte de ellos está construida al terminar una actividad de la WBS.

2. La regla del 100% ⁽²⁾

Enuncia:

“El próximo nivel de descomposición de un componente de la WBS (hijo) debe representar el 100% del trabajo aplicable al componente de nivel superior próximo (padre)”.

Asegura:

Que a medida que se va descomponiendo la jerarquía, no se pierde ningún componente del Alcance.

• Cada nivel de descomposición incluye el 100% de los entregables del componente padre.
• El resultado final de la WBS es un conjunto de paquetes de trabajo que definen completamente todos los entregables requeridos.

3. El PMI y la WBS ⁽³⁾

PMBOK

El PMI fue variando con el tiempo la definición  de la WBS dada en el PMBOK.
Veamos cómo, según lo resumen Norman y Brotherton y ampliado con el PMBOK 2013 (5ta edic.).

• 1987: Un “árbol genealógico” orientado a actividades.
• 1996 / 2000: Un agrupamiento de los elementos del proyecto, orientado a entregables, que organizan y definen el alcance total del proyecto.
• 2004: Una descomposición jerárquica, orientada a entregables, del trabajo a ejecutar por el equipo de proyecto para lograr los objetivos del proyecto y crear los entregables requeridos. Organiza y define el alcance total del proyecto.
• 2008: Ídem 2004.
• 2013: Una descomposición jerárquica del alcance total del trabajo, a ejecutar por el equipo de proyecto para lograr los objetivos del proyecto y crear los entregables requeridos. (esto parece un reordenamiento de los términos, en esencia se dice lo mismo)

Es interesante observar el cambio, desde la primera definición a la última, reconociendo a medida que pasa el tiempo la visibilidad del entregable (producto intermedio o final) por sobre la actividad, sobre todo a los ojos del cliente.


4. Estándar de WBS⁽4)

Muy recomendable el Practice Standard for Work Breakdown Structures – 2006 del PMI.
Utiliza como ejemplo la construcción de una bicicleta. Excelente explicación del tema.


Resumiendo:

Es una práctica muy útil, una herramienta muy visual para mostrar los límites del proyecto, estimar, planificar, etc..

Sin embargo, al menos en mi experiencia personal, no es algo demasiado conocido formalmente fuera del entorno de la comunidad de Proyectos (miembros de equipos de proyecto, capacitadores, consultores, etc.). 
Notable, no es así?

Bibliografía:

(1) Work Breakdown Structure - the foundation for project management excellence.Norman, Brotherton y Fried.

(2) Effective work breakdown structures. Haugan, G.
(3) PMBoK(R) 5th edition. 
(4) Practice Standard for Work Breakdown Structures. PMI.


Parte de este material fue publicado en Excelza en el año 2010.

¿Encajar una pieza cuadrada en un hueco redondo? El Jefe de Proyecto y la Organización no orientada a proyectos

Varios de Uds. se habrán encontrado con este tema. Yo también.

¿Es posible desarrollar una organización por proyectos, práctica de Administración por Proyecto, el rol de Jefe de Proyecto, en una Organización no orientada a proyectos?

¿La típica matriz es viable en estas organizaciones?

¿Se puede asignar responsabilidad sin dar autoridad?

Organizaciones no orientadas a proyecto

Las organizaciones funcionales típicas, no orientadas a proyecto, y presentes en gran cantidad de empresas, representan a primera vista, como explica Kerzner⁽¹⁾, un desafío para desarrollar la práctica de Administración por Proyectos y el rol del Jefe de Proyecto.

Como lo demuestran la teoría y la práctica 

• Las personas residen en las áreas funcionales que llevan adelante la producción, cada uno con una serie de tareas asignadas normalmente por especialidad.
• Los proyectos son disruptivos en esta rutina ya que reasignan los recursos hacia otras actividades.
• Si bien los proyectos implementan la estrategia de la Compañía en áreas de interés, la producción es lo que la mantiene operando y genera los ingresos del día a día. De allí podrían provenir los primeros problemas de prioridad.

¿Qué inconvenientes se presentan con los proyectos en este tipo de organizaciones?

• El ya conocido problema de los silos funcionales.
• La inexistencia de la visión de proyecto como un todo con un objetivo único, o la visión del mismo a través de los silos funcionales, con sus objetivos particulares.
• La posible demora de las tareas del proyecto en estos silos, debido a prioridades sobre los recursos, en conflicto con las tareas funcionales ⁽²⁾ . 
• Priorización del día a día sobre el calendario del proyecto (la producción tiene urgencias que no pueden esperar y el proyecto aún no las vive y se cree que las puede recuperar).

¿Qué problemas se presentan con el rol de Jefe de Proyecto?

• El rol del Jefe de Proyecto es muchas veces informal.
• Es un trabajo de tiempo compartido. Un Jefe de Proyectos administra 7 proyectos (¿son proyectos?).
• Tiene escaso o nulo control del presupuesto del proyecto. 
• Tiene poca o ninguna autoridad sobre la asignación de recursos (el típico “el equipo ya me llega armado”). 
• Tiene en general poca autoridad debido a su posición en la estructura, en muchos casos subordinada a los mismos jefes funcionales que deben asignarle las personas. 
• Los responsables de las áreas funcionales tienen poca voluntad para aceptar la autoridad del Jefe de Proyecto.

 Pero… ¿En qué casos una Organización no orientada a proyectos necesita trabajar por proyecto?

Una pregunta interesante es por qué necesitaríamos esta organización, si puede traer tantos inconvenientes.

Un buen resumen ⁽³⁾ confirmado por la práctica es el siguiente:

• Al desarrollar un tema nuevo, debe intervenir más de un área de la Organización, siendo crítico que trabajen coordinadas, por ejemplo, el rediseño de un sistema central a la empresa con nuevas tecnologías y criterios de calidad más estrictos, el desarrollo de nuevos procesos, la instalación de un ERP que cambiará la forma de operar de la Compañía, u otros casos similares. 
• Cuando hay dudas acerca de la conveniencia de una tecnología y conviene probar en un ambiente controlado (el del proyecto). 
• Cuando hay restricciones económicas o de recursos importantes para desarrollar una nueva idea, que exigen un estricto control de estas variables. 

Como vemos, estas pueden no ser tareas rutinarias en las organizaciones.

Finalmente… ¿Podremos hacer encajar las piezas?

Las siguientes ideas tratan de ayudar a aclarar algunos de estos temas, a evitar que el rol de Jefe de Proyecto esté “pintado” en la Organización y también a que se comprenda el sentido de la organización "proyecto":

• No engañarse y aceptar que no todo emprendimiento es un proyecto ni puede organizarse como tal. Llamar a algo proyecto, no lo convierte en uno.
• Tener en cuenta que la organización por proyecto puede convivir con la funcional para cierto tipo de emprendimientos, por ejemplo como los mencionados en el apartado anterior. 
• Si se encara esta organización de proyecto, formalizar los roles a través de definir su autoridad y responsabilidad, pudiendo incluirlo en el Plan de Carrera o su equivalente.
• Ubicar el rol de Jefe de Proyecto en la estructura de modo tal que acceda a los mismos niveles de decisión que los Jefes Funcionales, ya sea en forma directa o a través de un sector que los agrupe.
• Capacitar en la práctica de Administración de Proyectos.
• Comunicar, comunicar y comunicar a todos los interesados la idea de este tipo de organización, el rol del Jefe de Proyecto y la práctica de Administración de Proyectos.
• Evitar en todo lo posible la continua injerencia de los Jefes Funcionales en los trabajos del Proyecto y sobre las personas asignadas.
• Asignar la responsabilidad completa del Proyecto al Jefe de Proyecto y la correspondiente autoridad.
  
• No desperdiciar el nombre "Jefe de Proyecto", si no lo es. Hay alternativas que proponen la literatura y la experiencia que definen mejor la posición. "Coordinador de Proyectos", "Asistente de Proyectos", etc..Es muy común sobre todo en empresas y proyectos de tamaño importante una multitud de “jefes de proyecto”, algunos cuya labor es el registro administrativo de las variables del proyecto (fundamentalmente tiempo, costo y alcance) pero sin decisión sobre ellas. Es decir efectúa el seguimiento pero las actividades de control y decisión de cambios está fuera de su responsabilidad. Convendría entonces revisar los nombres para no crear confusión.

Volviendo al título, si la pieza es cuadrada y el hueco redondo, obviamente será difícil el encaje. Pero si adecuamos ambas partes, aunque no sea en forma perfecta, explicando las diferencias y mostrando resultados, seguramente lo lograremos.

Nota: Este entrada es una revisión de un artículo oportunamente publicado en nuestro blog Excelza en marzo de 2010.

Referencias

1. Project Management, H. Kerzner

2. PMBOK 4th Edition, PMI

3. Problems of Matrix Organizations, Davis and Lawrence, HBR