Project Management Institute

La oficina de proyectos en empresas medianas. Un caso práctico

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

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).

Características del Cliente

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).

Organización Original del Sector

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).

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

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
Propuesta de Nueva Organización del Sector

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

    img Sector de Responsables de Producto

  • Proceso de Desarrollo de soluciones

    img Sector Oficina de Proyectos

    img Sector de Desarrollo

    img Sector de Calidad

  • Proceso de soporte al servicio

    img Sector de Soporte

    img 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)
Ejemplo de Equipo de Proyecto

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

Advertisement

Advertisement

Related Content

Advertisement