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.
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?
ResponderEliminarPor 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.
ResponderEliminarSaludos.