domingo, 10 de junio de 2012

La importancia de conocer nuestros límites y saber manejar cosas “pequeñas”



La importancia de conocer nuestros límites y saber manejar cosas “pequeñas”

El ser humano tiene sus límites y, en particular, cada uno de nosotros tenemos los nuestros que difieren de los del vecino. De la misma forma las organizaciones tienen los suyos, pero no sólo en las factorías de software, call centers of fuerza de ventas, también lo tienen en las oficinas de proyecto (PMO), estrategia, e incluso en el board de directors.

Muchas organizaciones fracasan en su estrategia porque no son capaces de entender dónde están sus límites, cuáles con sus capacidades como organización, y por establecer objetivos inalcanzables o irrealistas que se convierten en auténticas losas rígidas, inflexibles y desmotivadoras para los empleados, partners y proveedores.

TOGAF habla de Architecture Capabaility Framework como una serie de técnicas y herramientas para conocer nuestros límites y establecer procedimientos, normas y políticas que gobernarán nuestra transformación, desde las fases preliminares del ciclo ADM (Architecture Development Methodology), hasta las fases finales F.Migration Planning, G. Implementation Governance, o H. Architecture Change Management.

Desde mi experiencia, muchas organizaciones son capaces de avanzar en el ciclo ADM pese a tener limitaciones de recursos, presupuesto o información en la elaboración de la target architecture, incluso definen con éxito los proyectos e iniciativas que cubren el gap entre la arquitectura actual y la arquitectura objetivo (business, information systems, and technological), pero donde rotundamente fracasan es en su puesta en marcha, implementación y control y monitorización.

Es normal que se identifiquen cientos de proyectos/iniciativas como resultado del ciclo ADM. Yo suelo deccir que no sé manejar 200 cosas distintas, que enseguida pierdo el control de muchas de ellas. Sin embargo sí puedo gestionar y controlar 20 ó 30. La agrupación de Proyectos en Programas facilita esta labor.

Recordemos la definición que da el Project Management Institute (PMI) en el libro ”The Standard of Program Management” (2nd Edition) relativa a programas y proyectos: En concreto, define Programa de la siguiente manera: 
  • A Program is a related group of projects managed in a coordinated way to obtain benefits and control not available from managing them individually”. Que básicamente viene a decir que un Programa es una serie de proyectos relacionados en los que si se coordina su ejecución se obtendrían más beneficios que si se ponen en marcha individualmente.

Un Enterprise Architect aporta mucho valor añandido en la fases E. y F. del ciclo ADM si es capaz de agrupar proyectos relacionados entre ellos en programas que sí sean manejables. Muchos equipos fracasan porque no son capaces de entender esto y, en concreto, muchos líderes y ‘decision makers’ de grandes corporaciones naufragan ante una lista interminable de proyectos con dependencias que no entienden, costes agregados y plazos que van más allá de sus expectativas de permanencia en el puesto.

Hagamos la vida más fácil y conozcamos nuestras limitaciones y las de nuestra organización para hacer realidad nuestros objetivos.


2 comentarios:

  1. Algo importantisimo es que nadie se quiere ensuciar en la operación y las fracasos también es porque propones castillos en el aire SIN CONOCER LA OPERACIÓN, mucho menos los directivos lo hacen, ¿entonces como entienden al negocio?

    ResponderEliminar
  2. Por eso es tan importante entender la estrategia (dónde vamos y cómo lo que queremos hacer) y tener la esposorización de la organización para derrumbar carros, carretas, molinos de vientos, trogloditas, cromañones y amigos de lo estático.
    Saludos.

    ResponderEliminar