La oficina de proyectos en empresas

medianas. Un caso práctico

The project office in medium-sized companies. A practical cas

Martinez, R. (2004). La oficina de proyectos en empresas medianas. Un caso práctico: The

project office in medium-sized companies. A practical case. Paper presented at PMI® Global
Congress 2004—Latin America, Buenos Aires, Argentina. Newtown Square, PA: Project
Management Institute.

Resumen.

El Problema

El caso describe el rediseño de los procesos y la organización que los soporta, llevada a
cabo en una empresa de venta minorista que encara un proyecto de crecimiento al doble
de su capacidad en un horizonte de 5 años.
Por el tipo de negocio de la Empresa, su área de Tecnología Informática debe evolucionar
de acuerdo al crecimiento esperado para el resto de las áreas.
Las situaciones que enfrenta la Gerencia General y la Gerencia de Tecnología Informática
se relacionan con:
• Cómo manejar la expansión del área de TI, para que brinde soporte al negocio, sin
que ello implique duplicar el personal actual.
• Determinar qué procesos son críticos, cómo se los mide, cuáles son
las competencias requeridas y la organización que soporta dichas competencias.
• De qué manera la Gerencia General puede evaluar el comportamiento del área de
TI respecto del resto del negocio, cuáles deberían ser los Indicadores Clave de
Performance que muestren esto objetivamente.

La Solución
El trabajo muestra las distintas decisiones que se fueron tomando, para resolver los
problemas que se presentaron. Qué procesos se definieron, los nuevos roles y
competencias propuestos y cómo la introducción de una estructura como la Oficina de
Proyectos, ayudo al objetivo.
Se analiza también el tipo de Oficina de Proyectos implementada y cuales fueron
desechadas y porqué, su organización y competencia y la autoridad y responsabilidad de
sus integrantes.
Se muestra asimismo, cómo la Oficina de Proyectos, en conjunto con los otros sectores
definidos pueden brindar a la Alta Gerencia un Tablero de Control que le de información
objetiva de un sector tan sensible como Tecnología Informática en una Empresa.

Introducción

El contexto

La industria de la venta minorista, retail, es una de las más críticas en lo concerniente a

control de costos y velocidad de respuesta a nuevas oportunidades de negocio y
crecimiento. El Sector de Tecnología Informática de estas organizaciones debe brindar sus
respuestas al ritmo requerido por el negocio o, de otra manera, se convierte en un
obstáculo para éste (Ver Figura 1).

Figura 1 – Características del Cliente

La Gerencia General y la Gerencia de Tecnología Informática nos convoca para colaborar
con ellos en el rediseño de los procesos y la organización de TI preparándolos para
acompañarlos en un crecimiento en locales y formatos que los llevaría a tres veces su
volumen actual, de 25 locales a 75, en un período de cinco años.

Objetivos

Las necesidades de la Gerencia se pueden resumir en forma concreta en los siguientes

puntos:
• Escalabilidad: Desarrollar una Organización que permita crecer junto con el
negocio.
• Cumplimiento: Honrar los compromisos como rutina y no como excepción.
• Calidad: Incorporar procesos que garanticen la conformidad con la solución final
obtenido.
• Demanda: Disminuir la demanda insatisfecha de requerimientos.
 • Costos: Desarrollar la conciencia de costos en el sector de TI.
• Motivación: Evitar la rotación del personal de TI producto de la sobrecarga de
trabajo.
• Visibilidad: Mejorar la inserción de la Gerencia de TI en el negocio haciendo visible
su performance.

Análisis del Sector de TI encontrado

Fortalezas:
Un equipo de trabajo integrado, con gran sentido de pertenencia a la Organización, con un
importante conocimiento funcional del negocio, la edad promedio y el nivel educativo
eran los adecuados para las distintas funciones.
Debilidades:
Básicamente expresadas por las necesidades de la Gerencia expresadas en el punto
anterior. Una Organización de TI con problemas de cumplimiento, calidad y motivación de
sus integrantes.
Observaciones Adicionales
La estructura organizativa encontrada era la típica funcional de una Gerencia de TI, un
área de Desarrollo, una de Soporte e Infraestructura y una de Operaciones, dependiendo
de ellas distintas funciones específicas de cada sector (Ver Figura 2).

Figura 2 Organización Original del Sector

La Organización de TI creció al ritmo del negocio, cubriendo la demanda de nuevos
trabajos incorporando recursos sobre la estructura existente. El día a día no hizo posible
analizar la efectividad del proceso aplicado para lograr las soluciones.
El Usuario final no está incorporado al proceso de obtención de soluciones de TI sino que
espera que la misma le sea provista, con un resultado incierto acerca de su aceptación.
El reporte y la resolución de incidentes se efectúan por diversas vías informales y
normalmente el Usuario no está suficientemente capacitado en las diversas soluciones
informáticas.
El método informal de trabajo aplicado no genera motivación por la indefinición de roles y
responsabilidades que conlleva.

La tarea a realizar

Por lo expresado en los puntos anteriores, la tarea a desarrollar estaba relacionada con el
ciclo de vida de los procesos -Descubrimiento, Diseño, Despliegue, Ejecución, Monitoreo,
Interacción, Control, Análisis y posterior Optimizaciónpara el Área en análisis, su
estructura organizativa y la incorporación de nuevos procesos y métodos para soportar las
prácticas donde correspondiera (Smith, H. 2003).

Los problemas encontrados

Los problemas encontrados se pueden resumir en:

• Gran concentración de poder y presión por satisfacer las demandas en la Jefatura
del Área de Desarrollo
• Actitudes heroicas en el personal expresadas fundamentalmente en trabajo
adicional
• Atención a Usuarios diseminada a lo largo de toda la estructura.
• Diversidad de criterios para planificar, desarrollar y controlar las actividades,
dependiendo exclusivamente de la persona responsable.
• Tareas de soporte y mesa de ayuda interrumpiendo las actividades normales de los
especialistas, con los problemas que ello acarrea tanto para la persona
interrumpida, como para el Proyecto en el cual se desempeña.
• Incorporación tardía en el desarrollo de las soluciones de los diversos grupos como
Soporte y Operaciones.
• Carencia de indicadores objetivos de la performance del sector.
Las oportunidades existentes

La necesidad de soportar el crecimiento y los diversos inconvenientes percibidos por la

Empresa y el personal de TI para prestar el servicio requerido nos permitió entonces
plantear los siguientes frentes de trabajo:
• Negocio: Mejorar el cumplimiento e integrarse totalmente al negocio.
• Focalización en la gente: Aprovechar el capital humano existente y motivarlos con
un proyecto desafiante.
• Excelencia: Formalizar el concepto de calidad y establecer estándares de
excelencia.
• Estructura organizativa: Definir la estructura en base a los procesos que se
soportan estableciendo responsabilidades precisas.

Propuesta de Solución

Se identificaron los procesos de creación de valor (Agarwal, R., et al., 2002, Porter, M.
1985) (Ver Figura 3).

Figura 3 Modelo de Procesos de Creación de Valor y Procesos de Soporte

Procesos

Estos pueden resumirse en:

• Proceso de Atención al Negocio
• Proceso de Desarrollo de soluciones
• Proceso de Soporte al Servicio
Se identificaron además los procesos de soporte correspondientes.

Indicadores

Se definieron para cada proceso de valor sus correspondientes indicadores así como los
roles responsables de producirlos.
• Proceso de Atención al Negocio: Indicadores de satisfacción del usuario, estado de
los requerimientos e innovaciones aportadas al negocio. Responsabilidad de la
Producción del Indicador: Responsables de Producto.
• Proceso de Desarrollo de soluciones: Indicadores de proyectos en cartera,
proyectos iniciados, proyectos terminados y otros estados de proyecto.
Información de desvíos y análisis de los mismos. Responsabilidad de la Producción
del Indicador: Jefe de la Oficina de Proyectos.
• Proceso de Soporte al Servicio: Indicadores de utilización del Help Desk, up-time
de la infraestructura. Responsabilidad de la Producción del Indicador: Jefe del
Sector de Soporte.
• En cada caso para cada indicador se definieron valores objetivos y situación
respecto a esos valores.

Diseño Organizativo

En base a estos procesos, se redefinió la estructura organizativa derivando en los

siguientes sectores (Ver Figura 4):
• Sector de Responsables de Producto
• Sector Oficina de Proyectos
• Sector de Desarrollo
• Sector de Calidad
• Sector de Soporte
• Sector de Operaciones
Figura 4 Propuesta de Nueva Organización del Sector
La relación Proceso-Organización Responsable es la siguiente
• Proceso de Atención al Negocio
o Sector de Responsables de Producto

• Proceso de Desarrollo de soluciones

o Sector Oficina de Proyectos
o Sector de Desarrollo
o Sector de Calidad

• Proceso de soporte al servicio

o Sector de Soporte
o Sector de Operaciones
Justificación de la propuesta efectuada

Para el Proceso de Desarrollo de Soluciones, y la implementación del Sector Oficina de

Proyectos, objeto de este trabajo, el análisis de la situación existente nos llevó a algunas
de las siguientes conclusiones.
• La incorporación del concepto de proyecto para soportar al Proceso de Desarrollo
de Soluciones nos ayudaría a formalizar compromisos de objetivos, responsables,
tiempos y recursos.
• La propuesta de creación de un Equipo de Proyecto con roles y responsabilidades
definidos para cada uno de sus integrantes colaboraría con nuestro objetivo de
mejorar la motivación y ayudaría a iniciativas de plan de carrera, competencias,
etc. (Ver Figura 5)

Figura 5 – Ejemplo de Equipo de Proyecto

• La concentración de responsabilidad sobre los proyectos en un sector, la Oficina de
Proyectos, nos permitiría trabajar sobre una de las debilidades principales de la
organización anterior, el cumplimiento de la demanda insatisfecha, pudiendo
obtener indicadores precisos acerca de este tema.
• La Organización resultaría ser más flexible en cuanto a la cantidad de recursos,
aprovechamiento, tipo y modalidad de adquisición de los mismos que se requiere,
en función a la cartera de proyectos que se está administrando. Esto permitiría
ampliarse o contraerse, dentro de ciertos límites, en la estructura operativa en
función a la demanda.
Alternativas analizadas

Otros análisis efectuados resolvieron los siguientes temas

• Perfil de la Oficina de Proyectos
• Ubicación en la Organización del rol de Jefe de Proyecto
• Tratamiento del mantenimiento y evolución de las soluciones existentes.

Perfil de la Oficina de Proyectos

• De acuerdo a la literatura (Miranda, E., 2003), los distintos diseños organizativos
que puede tomar una Oficina de Proyectos se ajustan a los siguientes patrones:
• La Oficina de Proyectos tipo Administrativo, define procesos y prácticas pero no
interviene en las decisiones de los proyectos.
• La Oficina de Proyectos tipo Consejero, guía, aconseja e informa sobre el estado de
los proyectos y puede ayudar en la toma de decisiones.
• La Oficina de Proyectos tipo Gerente, prepara el plan de proyectos, recursos y
presupuestos y gerencia el conjunto de proyectos.

El diseño organizativo seleccionado fue el de la Oficina de Proyectos tipo Gerente,

integrada por un Jefe de Oficina de Proyectos, quien tenía la responsabilidad por el Sector
y la Cartera de Proyectos, así como de producir los indicadores del proceso de Desarrollo
de Soluciones.
Los Jefes de Producto, en función a la demanda, generan la Cartera de Proyectos. Los
proyectos una vez aprobados para su ejecución entran en el área de responsabilidad de la
Oficina de Proyectos.
Ubicación en la Organización del rol de Jefe de Proyecto
Se decidió ubicar el rol de Jefe de Proyecto, dentro de la estructura de la Oficina de
Proyectos en lugar de pertenecer a otro Sector. La resultante de esto es:
• La Oficina de proyectos provee el rol de Jefe de Proyecto.
• Los Jefes de Proyecto dependen jerárquicamente del Jefe de la Oficina de
Proyectos.
• El Equipo de Trabajo depende jerárquicamente del Jefe de Proyecto durante la
ejecución del mismo.
Tratamiento del mantenimiento y evolución de las soluciones existentes.
Los mantenimientos a la plataforma de soluciones existentes, también fue encarada como
proyecto con un presupuesto periódico y equipo designados para la resolución de los
cambios requeridos.
Criterio con que se seleccionaron las alternativas

Los criterios con que se juzgaron las alternativas antes expresadas fueron:
Oficina de Proyectos Tipo Gerente: debido a que la Organización no tenía incorporada la
cultura de proyecto en su modalidad de operación, el desarrollo de una posición
centralizadora de la responsabilidad que proveyera además la competencia de Jefe de
proyecto, se encontró adecuada para una rápida difusión.
Asimismo, debido a que estábamos ante una Organización de TI relativamente pequeña,
este diseño organizativo no fue resistido.
En una organización de mayor tamaño, debería revisarse el modelo más conveniente, ya
que los distintos intereses y la cantidad de sectores intervinientes pueden hacer complejo
este modelo.
Ubicación de los Jefes de Proyecto: se decidió que estos se incorporaran a la Oficina de
Proyectos y dependiendo del Responsable del Sector.
Se revisó asimismo la alternativa de la pertenencia a un Centro de Excelencia junto con
otros especialistas. Esto permitiría evitar la “fuga” hacia la Oficina de Proyectos de los
especialistas por considerarlo como un lugar de mejor status y salario.
Sin embargo se descartó, al menos en el comienzo esta alternativa. Esta decisión está
sustentada en la cultura funcional que poseía la Empresa, una orientación hacia una
organización de Centros de Excelencia (Clark, C., et al., 1997) o similares resultaría en un
cambio demasiado importante para ser absorbido sin resistencia por la Gerencia de TI,
dentro de los plazos de proyecto establecidos.
Organización del mantenimiento de aplicaciones como proyectos: esta decisión se
fundamentó en la idea de evitar áreas marginadas, dedicadas a mantener productos
obsoletos y que se rigieran por sus propias reglas organizativas y métodos de trabajo. La
organización de proyecto extendida a estas tareas permitió aplicar el concepto de equipo
de trabajo y métodos de trabajo similares al resto de las áreas e incorporar la idea de
versión de los productos. Con el concepto de versiones evitamos también la idea del
mantenimiento como un trabajo continuo.

La puesta en marcha de la mejora

Lo expresado hasta aquí respecto de los nuevos procesos y los cambios organizativos fue
puesto en marcha en forma gradual a medida que transcurrió el Proyecto.
La Oficina de Proyectos comenzó a operar de acuerdo a la modalidad prevista una vez
concluida la definición de roles y responsabilidades de las áreas y la necesaria capacitación
de sus primeros integrantes.
Los indicadores de performance de los procesos se produjeron por los responsables
previstos en el diseño de los procesos.
Se efectuaron ajustes al planteo original, consolidando varios de los procesos de soporte
en función a lo demostrado por la operación del nuevo modelo.
Se siguieron junto con el personal de la Empresa varios proyectos operando de acuerdo al
nuevo modelo, transfiriendo totalmente la responsabilidad de la mejora al Equipo de
Mejora interno del Cliente, quien continuó luego en una modalidad de mejora continua.
Se planificaron evaluaciones periódicas, la primera a los seis meses de entregado el
Proyecto y el resto en forma anual. Se concluyó el trabajo de consultoría a satisfacción de
los dos actores fundamentales involucrados, la Gerencia General y la Gerencia de
Tecnología Informática.

Lecciones aprendidas

• El Cliente demanda soluciones completas sin interesarle la división funcional

dentro de TI por lo cual el enfoque de procesos es el adecuado para resolver esta
necesidad.
• Como todo proceso de mejora debe existir la necesidad para hacerlo y esta debe
estar fundada en urgencias y razones de negocio.
• El Sponsor del proyecto de mejora debe ser quien escuche las quejas del negocio
respecto al área que se quiera mejorar.
• El cambio cultural que implica para una organización funcional la incorporación de
procesos orientados a la operación por proyectos no debe ser minimizado.
• Debe adecuarse el sistema de recompensas (Andrews, D. y Stalick, S., 1996) para
promover, incentivar y reconocer aquellos miembros de la Organización que
logran los objetivos planteados por el nuevo modelo de procesos propuesto y no
incentivar viejas costumbres, útiles en otras estructuras pero nocivas en la nueva
modalidad de operación.
• La búsqueda y producción de indicadores de los procesos de valor es crítica. Estos
deben ser mantenidos en el mínimo número posible y deben ser presentados en
forma regular a la Dirección luego de concluido el proceso de mejora para analizar
la evolución de la misma.
• Como en todo cambio es importante crear la sensación de urgencia (Kotter, J.,
1996), de otro modo los viejos hábitos se impondrán sobre las nuevas ideas.
• Normalmente la implementación de este tipo de procesos se da en un momento
adecuado en que el negocio lo requiere, la Dirección está dispuesta a respaldar un
cambio importante tanto en lo político como en lo económico, y el Sector objeto
del cambio está dispuesto a experimentar un nuevo modelo de trabajo. Debido a
que la combinación de estos factores no es muy común, no debe desperdiciarse
una oportunidad de este tipo efectuando simplemente cambios cosméticos.
 • Un Equipo de Mejora, constituido exclusivamente por personal de la Empresa,
debe quedar a cargo de implementar, aconsejar y encontrar las mejoras futuras,
así como ajustar las propuestas, creando así un sistema de mejora continua.
Cualquier tipo de ayuda externa que se requiriera durante la primera parte del
proceso debe trasladar esa responsabilidad en este Equipo mucho antes de la
finalización del Proyecto de mejora.

Posibles optimizaciones al proceso de mejora ejecutado

• Las empresas compiten a través de la cadena de valor. Los procesos deben ser
explicitados y enseñados desde el primer momento y trabajar con ellos como
marco (Smith, H 2003, Hammer, M. 2001).
• Los conflictos de poder generados por las estructuras que se cambian, no deben
ser reemplazados por otros en la nueva estructura. Esto debe ser tenido en cuenta
desde el comienzo como un riesgo y monitorearlo continuamente.
• La adecuación, vía selección y capacitación, de los roles a las nuevas estructuras
debe ser hecha en forma simultánea con la creación de estas.
• Como todo cambio importante, una vez consensuada una dirección, esta debe ser
seguida sin admitir discusiones ni retrocesos. La práctica de la ejecución
demostrará los detalles que necesitan ser ajustados.
• El cambio en los modelos mentales, que son los marcos conceptuales que
utilizamos para negociar, en el sentido más amplio, no deben ser minimizados ya
que toda propuesta hecha por la Organización es filtrada por los miembros de la
misma a través de estos modelos. (Andrew, D 1996)
• Resulta de utilidad tomar un Modelo de Madurez como referencia puede ayudar a
incorporar las prácticas básicas mínimas en el orden adecuado. (Miranda, E. 2003,
Schlichter, J. 2003). Esto facilita la evaluación y permite referenciar los resultados a
un estándar.
Referencias

Agarwal, R., et al., (2002) Principles and models for organizing the IT function, MIS
Quarterly Executive Vol. 1 No. 1.
Andrews, D. y Stalick, S., (1996) Street Smarts for Business Reengineers, Englewood Cliffs,
NJ: Prentice Hall.
Clark, C., et al., (1997) Building Change-Readiness Capabilities in the IS Organization:
Insights From the Bell Atlantic Experience MIS Quarterly Vol. 21 No. 4.
Hammer, M., (2001) The Agenda, New York, Crown Business
Kotter, J., (1996) El líder del cambio, McGraw Hill.
Miranda, E., (2003) Running the successful hi-tech project office, Artech House.
Porter, M. (1985) Competitive Advantage: Creating and Sustaining Superior Performance,
New York, Free Press
Schlichter, J. (2003), A primer on PMI OPM3, obtenido de http://www.opmexperts.com ,
referencias varis en www.pmi.org.
Smith, H y Fingar, P. (2003) Business process Management, the third wave, Tampa,
Florida, Meghan-Kiffer Press
This material has been reproduced with the permission of the copyright owner.
Unauthorized reproduction of this material is strictly prohibited. For permission to
reproduce this material, please contact PMI or any listed author.
© 2004, Raúl Martínez
Originally published as a part of 2004 PMI Global Congress Proceedings – Buenos Aires,
Argentina