Motorola recurre a la administración de carteras de proyectos
Fuente: Laudon, K. y Laudon, J. (2012). Sistemas de Información Gerencial. (12 ed.). Pearson.
Capítulo 15, pp. 550-551)

Lee el caso Motorola recurre a la administración de carteras de proyectos de las páginas 550 y 551 del libro de texto y analiza la siguiente discusión.

Motorola es una empresa multinacional con más de 53 000 empleados basada en Schaumburg, Illinois, muy cerca de Chicago. Ha crecido en gran medida a través de fusiones y adquisiciones que le trajeron miles de diferentes sistemas. Está organizada en tres segmentos: de dispositivos móviles, movilidad y redes para el hogar, y soluciones de movilidad empresarial. Motorola aprovechó la reciente recesión económica para revisar a fondo su negocio y encontró áreas en las que podría llegar a ser más eficiente. La empresa cuenta con 1,800 sistemas de información y 1,500 empleados de sistemas que trabajan en 1,000 proyectos por año. A esto se añade el hecho de que la empresa subcontrata gran parte de su trabajo de TI a contratistas externos. Muchos empleados estaban trabajando en proyectos similares o en reunir los mismos conjuntos de datos, sin saber que otros en la compañía estaban haciendo lo mismo. Ciclos redundantes de actividad causaban trabajo extra, costos adicionales, y el desperdicio de recursos.

Motorola optó por adquirir el software Project and Portfolio Management center de HP (o HP PPM). El sistema creó una ubicación central para toda la información asociada con el análisis de procesos de la compañía. Además, el software ofrece una fuente centralizada de información crítica, tal como la cantidad de dólares de inversión utilizados por un proceso y las prioridades de las solicitudes de negocios.

Ahora puede gobernar todo su portafolio de TI utilizando una amplia gama de herramientas, incluyendo la priorización de objetivos; múltiples niveles de entrada, revisión y aprobación, además de la visibilidad en tiempo real de todas las áreas del negocio. Usuarios de PPM de HP, Motorola tiene datos sobre los recursos, presupuestos, previsiones, los costos, los programas, los proyectos, y la demanda global de TI; todo actualizado al minuto.

Si se utilizan correctamente los sistemas de administración de proyectos en una empresa de este tamaño, podrían reducirse costos, aumentar su productividad y dar a los administradores la oportunidad de priorizar el uso de recursos. El software ayuda a los administradores a comparar propuestas, proyectos y actividades operacionales contra los presupuestos y los niveles de capacidad de recursos. La información de análisis de procesos se encuentra centralizada. Los empleados de TI y los administradores tienen acceso rápido y fácil a todas y todos los datos relativos a los procesos de negocio de la compañía.

El éxito de Motorola con el software HP PPM se mide por los siguientes factores:

Lee las lecturas obligatorias del tema y enseguida revisa la siguiente discusión.

Cuanto más complejo, más riesgo; esto es bastante fácil de entender, pero difícil de manejar. Los riesgos asociados con los proyectos de TI deben ser claramente definidos y discutidos. Los tres riesgos principales son: tamaño del proyecto, estructura del proyecto, y experiencia con la tecnología.

Haz clic en cada apartado para revisar la información.

Como afirman Laudon y Laudon (2012), cuanto mayor sea el tamaño del proyecto, más grandes serán los dolores de cabeza. Es bastante evidente que la coordinación de dos o tres personas que trabajan en un pequeño proyecto de desarrollo del sistema es más fácil que organizar 20 personas que trabajan en uno enorme, que involucra a toda la organización. Cuanto más estructurado el proyecto, más gente va a entender lo que se espera de ellos. Cuantas más personas conozcan, entiendan y están familiarizados con el hardware y el software, la implementación será más fácil y se cometerán menos errores.

El problema principal estriba en que si un proyecto de sistemas se empieza a retrasar, la demora no se puede solucionar simplemente contratando más gente. Agregar más personas a un proyecto que ya va tarde y por encima del presupuesto generalmente no ayudará, sólo exacerbará el problema, pues se perderá tiempo entrenando a los nuevos recursos y se complicará la comunicación con el grupo. Es como tratar de apagar un incendio echándole gasolina.

Esa es la teoría detrás del libro del mito hombre-mes de Brooks. Si estás construyendo una casa, no se pueden hacer las paredes antes de tener los cimientos listos. Tampoco instalar la alfombra antes de tener los techos en su lugar, no importa cuántos instaladores de alfombra hayas contratado. Bueno, se puede, pero tú vas a tener un lío. Los mismos conceptos aplican para un sistema de información. No se puede construir la pantalla de interfaz de usuario antes de saber qué elementos de datos debe llevar.

Un porcentaje muy grande de proyectos de sistemas de información sufren tropiezos porque no se lidió de manera adecuada con el proceso de cambio organizacional relacionado con la construcción del sistema. Esto requiere una administración del cambio cuidadosa. Lo importante es estar en comunicación constante con el usuario; comunicar, comunicar y comunicar, hacia arriba y hacia abajo de la cadena de mando. El hecho de que no se le diga a nadie la mala noticia no hará que esta desaparezca. La administración del cambio implica el manejo de su impacto organizacional asociado con una innovación, como en el caso de un nuevo sistema de información.

La implementación de un nuevo sistema no es sólo acerca de cómo poner el hardware y software en su lugar, también incluye el elemento humano del triángulo. Debe asegurarse de que está en sintonía con el hardware y el software. En esencia, se convierte en un agente de cambio hay que convencer a los usuarios que el sistema va a mejorar su mundo de trabajo y que el nuevo será mejor que el anterior. Si las personas van a perder sus puestos de trabajo a causa de él o si van a experimentar una diferencia significativa en el desempeño de sus responsabilidades, debe quedar claro en la comunicación con ellos.

Generalmente los usuarios y diseñadores tienen diferentes antecedentes y diferentes objetivos. Laudon y Laudon (2012: 541) presentan una buena idea de la brecha de comunicación usuario-diseñador, como gerente, tu trabajo consiste en cerrar esa brecha para ayudar a asegurar el éxito del nuevo sistema.

Si hay muy poco debate y comunicación entre los técnicos y los no expertos en tecnología pueden resultar defectos de diseño y un proyecto mal implementado. En cambio, si se entiende de dónde viene cada parte, puede ayudar a hacer un mejor trabajo. Nunca puedes tener demasiada comunicación.

Otro elemento importante es el apoyo de la alta administración. Si a los gerentes no les gusta el nuevo sistema o le temen, ¿cómo podrían esperar que los trabajadores lo acepten? La mejor manera de conseguir la aprobación de los gerentes para apoyar y financiar el nuevo sistema es mantenerlos informados a cada paso del proyecto. Asegúrate de que sepan lo que está pasando. Después de todo, los administradores son gente también y tienen los mismos temores que cualquier otra persona.

Qué tan bien se manejen las modificaciones causadas por la implementación de un nuevo sistema en una organización puede significar el éxito o el fracaso del proyecto. Las áreas problemáticas están en el diseño, los datos, el costo y las de operaciones. Las principales causas del éxito o fracaso de la implementación son la participación de los usuarios, compromiso y apoyo de la alta administración, el nivel de complejidad y el riesgo del proyecto y la administración del proceso de implementación.

Existen diversas herramientas especiales que puedes utilizar para ayudarte a manejar la implementación de un nuevo sistema de información (herramientas de integración interna). En el peor de los casos, te ayudarán a comunicarte con todos en el equipo de implementación y en la organización en su conjunto. Utiliza la intranet de tu compañía tanto como sea posible para comunicar e informar.

Una gráfica de Gantt lista las actividades del proyecto y sus correspondientes fechas de inicio y fin. La gráfica ofrece una representación visual de la sincronización y duración de las diferentes tareas de un proyecto, así como los recursos requeridos. En una gráfica de Gantt, las actividades se listan en la columna izquierda; cada una representa un periodo de tiempo. Una barra inicia en la fecha en la que la tarea debe comenzar y se extiende hasta la columna de la fecha en la que la tarea debe concluir.

Las actividades en un proyecto deben organizarse para producir resultados tangibles. Las metas son el punto final de una actividad del proceso. Los entregables son los resultados del proyecto que se llevan a los clientes.

Divide el proyecto en tareas y calcula el tiempo y los recursos necesarios para completar cada tarea. Organiza tareas en forma concurrente para optimizar recursos. Minimiza las dependencias de tareas para evitar demoras causadas por una tarea que espera a otra para poder empezar.

Figura 1. Una gráfica de Gantt
Fuente: Laudon, K. y Laudon, J. (2012). Sistemas de Información Gerencial. (12^a ed.). Pearson.

Un diagrama de PERT es una herramienta de administración de proyectos que se utiliza para programar, organizar y coordinar las tareas dentro de un proyecto. PERT significa Técnica de Revisión y Evaluación del Programa (Program Evaluation and Review Technique), una metodología desarrollada por la Marina de Estados Unidos en la década de 1950 para administrar el programa de misiles submarinos Polaris.

El proceso para generar un diagrama de PERT es el siguiente:

	Identifica todas las tareas o los componentes del proyecto. Documenta las tareas en pequeñas fichas.
	Identifica la primera tarea que debe ser completada. Coloca la tarjeta apropiada en el extremo izquierdo de la superficie de trabajo.
	Identifica todas las demás tareas que se pueden iniciar simultáneamente con la tarea # 1. Alinea estas tareas ya sea por encima o por debajo de la tarea # 1 en la superficie de trabajo.
	Identifica la siguiente tarea que debe ser completada. Selecciona una tarea que debe esperar para comenzar hasta que la tarea nº 1 (o una tarea que se inicia simultáneamente con la tarea # 1) se haya completado. Coloca la tarjeta apropiada a la derecha de la tarjeta que muestra la tarea anterior.
	Identifica todas las demás tareas que se pueden iniciar simultáneamente con la tarea # 2. Alinear estas tareas ya sea por encima o por debajo de la tarea nº 2 en la superficie de trabajo
	Continúa este proceso hasta que todas las tareas estén secuenciadas.

Ahora hay que trabajar con las fechas y tiempos de cada actividad.

	Identifica la duración de cada tarea y coloca ese número en la casilla apropiada de cada ficha.
	Calcula las fechas de inicio de cada ficha. Las fichas que no dependen de nadie comienzan en la fecha 0. La fecha final sería la suma de la fecha de inicio más los días que toma la actividad.
	La fecha de inicio de la ficha que dependa secuencialmente de otra, sería la fecha final de la ficha anterior.
	Completa todas las fechas de inicio y finales más prontas para cada ficha.
	La fecha final de la última actividad sería la duración óptima del proyecto, el tiempo que tomaría completar el proyecto si todo saliera bien.

Figura 2. Un diagrama PERT
Fuente: Laudon, K. y Laudon, J. (2012). Sistemas de Información Gerencial. (12^a ed.). Pearson.

A final de cuentas, la administración del cambio en la estructura organizacional que resulta de la aplicación de un nuevo sistema es tan importante como la administración del propio sistema. Utiliza las herramientas de integración interna y externa adecuadas para controlar los factores de riesgo. Diseña la implementación del sistema con toda la organización en mente, incluyendo, sobre todo, el factor humano.

Hay herramientas de software comerciales que automatizan muchos aspectos de la administración de proyectos y facilitan el trabajo. Una herramienta de software de administración de proyectos normalmente cuenta con las siguientes capacidades:

Algunos ejemplos de estas herramientas serían Microsoft Office Project, EasyProjects, Vertabase, Project Workbench y OpenProj.

Este tema comienza con la descripción de las tres dimensiones de los riesgos de proyectos: el tamaño, la estructura y la experiencia con la tecnología. Se explica cómo la administración del cambio puede disminuir la tasa de fracaso potencial de los proyectos, independientemente de sus dimensiones. Muchos fallos suceden porque los desarrolladores no entendían los cambios de comportamiento que podría provocar el nuevo sistema. La falta de comunicación usuario-diseñador es un buen ejemplo de un problema común que puede causar que un proyecto de sistemas de información falle. Una de las maneras más eficaces de controlar los factores de riesgo es mediante el uso de gráficas de Gantt y diagramas de PERT.

A manera de reflexión, intenta responder por ti mismo las siguientes preguntas antes de dar clic para ver la respuesta.

Haz clic en cada pregunta para revisar su información.