Tarea #3

Caso de Estudio: Qué sucedió con el trabajo de equipo?

Como respuesta a las preguntas planteadas en el caso anoto lo siguiente:

1. Cite al menos dos valoraciones éticas que obvió Wilson en este caso.  Explique:

·         Artículo I inciso a: Aceptar la responsabilidad de sus acciones. 

Como ya hemos visto en clase, el GP no puede alegar desconocimiento de lo que sucede en su proyecto ni mucho menos tratar de justificar un error basado en esto, el proyecto ES su responsabilidad, por tanto no es correcto que reaccione con sorpresa y diga “no sabía que el proyecto estuviera retrasado” y mucho menos “mi ayudante me ha dicho...” La responsabilidad primaria es solo suya, él debe saber qué pasa, en qué momento pasa, quién hace qué y cuáles son los efectos de todas esas acciones.  No puede escudarse en que alguien más lo hizo por él, porque entonces, para qué está a cargo?  Ya sea lo que hizo o lo que dejó de hacer, debe afrontar la responsabilidad de esas acciones en el proyecto.

·         Artículo II inciso a: Ejercer el liderazgo necesario para el proyecto con el fin de promover una productividad máxima y al mismo tiempo esforzarse por reducir los costos. 

Considero que falló en su liderazgo, ya que no supo cohesionar a su equipo de trabajo para lograr un buen rendimiento, además, delegó ciertas funciones en su asistente sin la debida supervisión, permitiendo además que éste tomara ciertas atribuciones que no le competían y que de paso no supo manejar, ya sea por su juventud o inexperiencia, pero que al final provocaron no solo el retraso en la producción y el incremento en los costos del proyecto, sino un roce innecesario entre ellos y el área de producción, vital para el desarrollo de los proyectos de ésta empresa.

2. De la lectura de multiculturalidad de proyectos cite dos aspectos que al ser aplicados por Brown, generó conflicto en el resultado final esperado.  Explique:

·        Errores de comunicación: el tipo de comunicación utilizado generó efectos contraproducentes para el proyecto, ya que se optó por una comunicación “agresiva” que lo que provocó fue más bien el rechazo al proyecto como tal y su retraso.  El querer ejercer presión de una manera agresiva sobre un grupo que ya sabe como hacer su trabajo y que además es parte de una organización que reconoce la importancia de reducir costos y cumplir los tiempos de entrega, no fue una buena estrategia, ya que más bien se generó un conflicto entre departamentos con la consecuente “sacada de clavo” del departamento de producción.

·        Subestimó al personal de producción: al generar presión sobre el equipo de producción les dió a entender que no valoraba su trabajo ni su experiencia, pues como él mismo lo expresó a Wilson, “solo debía presionar un poco más a los de producción”.  Me parece que no se dió el tiempo de conocer bien la operación de la organización y su cultura, y actuó solo de acuerdo a su percepción de cómo debían manejarse las cosas.

3. De las dimensiones de la cultura propuestas por Hofstede, cual está presente en este caso y cómo se debería manejar por parte de Wilson. Explique:

Considero que es el Power Distance, ya que Wilson no hizo valer su liderazgo, no demostró su autoridad y más bien se mostró “débil” al no lograr que el proyecto avanzara de la forma prevista ni lograr la cohesión de su equipo de trabajo.  No apareció como un colaborador más, sino que más bien da la sensación de ser un lider ausente, quien delegó sus responsabilidades en su asistente.  No parece haber ido a negociar con el equipo de producción, no se comunicaba con ellos directamente ni tampoco mantenía informado al Vice presidente sobre el avance del proyecto, ya que éste se enteró de lo que sucedía a través de la auditoría.  Creo que Wilson no supo tomar ventaja del hecho de que la organización tiene bastante experiencia en el manejo de proyectos y por tanto, sabe de la importancia que tiene un GP; sin embargo, él no hizo valer ese respeto ya de por si otorgado por la empresa, sino que más bien, se desvalorizó frente a la organización.

4. Qué debería hacer McDowell para solucionar el problema. Explique:

Debe dejarle claro a Wilson cuáles son sus responsabilidades  y lo que se espera de su puesto.  Primordialmente, deberá hacer una confrontación entre las partes para hacer que se hablen y limar las asperezas generadas, lograr que se comuniquen cara a cara y se aclaren los malentendidos.  Ambas partes deben exponer sus puntos y lograr un acuerdo para seguir adelante con el proyecto sin más contratiempos de este tipo, evitando que la empresa pierda dinero con este proyecto en particular.

5. Realice una conclusión general del caso de estudio relacionado con las lecturas. Explique:

Una empresa que está basada en proyectos, donde toda la organización reconoce y está comprometida con la importancia de la calidad, el plazo y el costo, es una organización madura que sabe cómo manejar proyectos.

Llegar a imponer cosas, dificilmente será bien visto o bien recibido, sobre todo si se hacen de forma agresiva, y se puede llegar a interpretar que se hacen solo por el hecho de sentirse con poder para hacerlo.  Si a esto se le suma el ser nuevo en una organización como esta, donde la relación con las otras áreas es tan importante, es algo que debe manejarse con sumo cuidado, sabiendo a quién dirigirse y de qué manera y no “tirando a matar”

Retomando la pregunta inicial del caso: qué pasó con el trabajo en equipo? Aquí cada quien anduvo por su lado, no hubo un empuje parejo de todos los involucrados porque ni siquiera se comunicaban adecuadamente entre ellos, y no se logró llegar a ese punto de sinergia que se menciona en la lectura.  No hubo trabajo en equipo, nunca se fusionaron como tal, Brown, en vez de ver a producción como su aliado para sacar adelante el proyecto, los vio como una parte necesaria simplemente, a quien debía presionar para lograr lo que necesitaba, sin entender todo el trasfondo de su operación y la forma en que se manejan. Inexperiencia? Ansiedad por el poder? Arrogancia? Complejo de superioridad? Pueden ser muchos los factores que podrían haber influido en su comportamiento, pero también está el hecho de que su superior inmediato no fue una guía para él, aportando también al problema que se generó al final.

Aquí volvemos a la importancia de mantener una buena comunicación hacia todos los niveles y la necesidad de ejercer un liderazgo adecuado a cada situación.

Tarea #2

Caso de Estudio I: Innovative Technologies

Como respuesta a las preguntas planteadas en el caso anoto lo siguiente:

1. ¿Por qué es necesario usar metodologías de administración de proyectos?: Estas metodologías permiten un mayor control sobre todo lo relacionado con la planeación y puesta en marcha de un proyecto.  Permiten un manejo más ordenado y una mayor optimización de los recursos, así como poder ir midiendo los avances y ver si se va a cumplir con lo definido inicialmente.

El uso continuo de una metodología de Administración de Proyectos permite mejorar los procesos y minimizar los errores, además de facilitar la distribución equitativa de las personas, el tiempo y el capital invertido en el proyecto, sacando mayor provecho de los recursos existentes y haciendo estimaciones más precisas de los recursos necesarios a futuro.

Una estructura de Administración de Proyectos permite evaluar y monitorear adecuadamente cada una de las etapas, dotando de mayor control a la empresa para saber en qué estado se encuentra determinado proyecto.

2. ¿Solamente las empresas grandes deben de utilizar estas metodologías?: Las metodologías deben ser utilizadas por cualquier persona o empresa (sin importar su tamaño) que quiera desarrollar o dirigir un proyecto de forma óptima, ordenada, controlada, y no solamente por empresas grandes o que inviertan mucho en el desarrollo de proyectos.

Esto no solo les dará mayor control sino que probablemente disminuirá los costos de un proyecto que se haga sin ningún tipo de normativa o metodología.

3. ¿Debe la empresa Innovative Technologies migrar a una metodología formal de Administración de Proyectos?: Considero que sí debe integrar los estándares de Administración de Proyectos de manera más formal dado el crecimiento que se espera en la demanda de sus servicios.  Esto les permitirá tener gente con más bases que sean capaces de llevar a buen término sus proyectos y un control más efectivo sobre sus compromisos. 

Si bien la empresa, a pesar de no tener una dirección de proyectos formal, ha logrado mantenerse a flote y mentener sus ingresos constantes, no debe confiarse en que esto será siempre así, ya que mucho de su éxito es gracias al liderazgo positivo de su gerente y a la buena fama de sus empleados.

Sin embargo, debido al crecimiento proyectado en la demanda de sus servicios, se hace más evidente la necesidad de adoptar metodologías de administración de proyectos que les permitan cumplir de una forma más adecuada y segura con los compromisos adquiridos con sus nuevos clientes, y tener un mayor control de lo que se hace.

Caso de Estudio II: El Titanic

Lo calificaría como un proyecto no exitoso, ya que muy a pesar del éxito obtenido por el producto final, éste sobrepasó en mucho el presupuesto inicial así como el tiempo de entrega programado. 

Las restricciones utilizadas para analizar este caso fueron evidentemente TIEMPO y COSTO.  El alcance y la calidad del producto pueden haber estado muy por encima de lo proyectado, lo cual se refleja en la cantidad de premios ganados y en lo recaudado en taquilla, por lo cual no consideraría esas restricciones en esta evaluación negativa.

INVESTIGACION

a) CMMI: (En Español: Modelo de Integración de Madurez de Capacidades/ En Inglés: Capability Maturity Model Integration).  Es un modelo para la mejora y evaluación de procesos para el desarrollo, mantenimiento y operación de sistemas de software.  Las mejores prácticas CMMI se publican en documentos llamados MODELOS.  Actualmente hay 3 áreas de interés cubiertas por los modelos CMMI: Desarrollo, Adquisición y Servicios.

El objetivo de CMMI es establecer una guía que permita a las organizaciones mejorar sus procesos y su habilidad para organizar, desarrollar, adquirir y mantener productos y servicios informáticos.

Son cinco los niveles de madurez que establece CMMI:

1.    Inicial

2.    Repetible

3.    Definido

4.    Administrado

5.    Optimizado

Cabe destacar que el objetivo principal de estos niveles de madurez, es lograr un nivel de estandarización adecuado para cada compañía respecto a sus procesos de desarrollo de software, con la finalidad de gestionar los proyectos de software adecuadamente y así lograr cumplir con los objetivos planificados para dicho proyecto.

El modelo CMMI indica la necesidad de administración de las etapas tempranas de un proyecto a través de la planificación y como todo modelo describe el “QUE” se debe hacer pero no el “COMO” hacerlo.

b) ITIL: (En Español: Biblioteca de Infraestructura de Tecnologías de Información/ En Inglés: Information Technology and Infraestructure Library).  Es el estándar más ampliamente conocido para la gestión de los servicios de Tecnologías de la Información (TI).  Es un marco de trabajo de las buenas prácticas destinadas a facilitar la entrega de servicios de TI.

ITIL se centra en brindar servicios de alta calidad para lograr la máxima satisfacción del cliente a un costo manejable. Para ello, parte de un enfoque estratégico basado en el triángulo procesos-personas-tecnología. En otras palabras: determina la forma de ejecutar procesos estándar ayudados de la tecnología para lograr la satisfacción de las personas, usuarios de los servicios de TI.

c) COBIT: (En Español: Objetivos de control para la Información y la Tecnología Relacionadas/ En Inglés: Control Objectives for
Information and Related Technology ).  Brinda buenas prácticas a través de un marco de trabajo de dominios y procesos, y presenta las actividades en una estructura manejable y lógica.  Estas prácticas están enfocadas fuertemente en el CONTROL y menos en la ejecución.

Está compuesta de 34 objetivos de alto nivel que cubren 318 objetivos de control (específicos), clasificados en 4 dominios:

1.    Planificación y Organización

2.    Adquisición e Implementación

3.    Entrega y Soporte

4.    Supervisión y Evaluación

El marco de trabajo de COBIT tiene un triple enfoque:

· Enfocado al management: Puesto que provee a la Administración de una base de mejores prácticas con las cuales se pueden tomar decisiones de TI e inversión.

· Enfocado a los usuarios de IT: Debido a la seguridad que les brinda para el control de objetivos y procesos.

· Enfocado a auditores: Debido a que permite identificar problemas de control de TI dentro de la infraestructura de TI de la compañía.

d) ISO/IEC 27000: es un conjunto de estándares desarrollados (o en fase de desarrollo) por la International Organization for Standarization (ISO) y por la International Electrotechnical Commission (IEC).  Proporcionan un marco de gestión de la seguridad de la información utilizable por cualquier tipo de organización, pública o privada, grande o pequeña.

La ISO 27000 es realmente una serie de estándares que proporciona una visión general de las normas que componen la serie, una introducción a los sistemas de Gestión de Seguridad de la Información, una breve descripción del proceso Plan-Do-Check-Act y términos y definiciones que se emplean en toda la serie.

Como punto adicional quisiera presentar una tabla comparativa entre tres de los estándares mencionados anteriormente:

Item	COBIT	ITIL	ISO27000
Función	Mapeo de procesos de TI	Mapeo de la Gestión del Nivel de Servicio de TI	Marco de Seguridad de la Información
Area	4 Procesos y 34 Dominios	9 Procesos	10 Dominios
Emisor	ISACA	OGC	Junta ISO
Implementación	Auditar el sistema de Información	Gestionar de nivel de servicio	Cumplimiento del estándar de seguridad
Consultor	Firma de Contabilidad, Empresa de Consultoría en TI	Empresa de Consultoría en TI	Consultoría de TI, empresa de seguridad, Consultor de la Red

Las consultas para esta tarea fueron hechas a:  www.wikipedia.com, www.iso27000.es, www.monografias.com, IT Governance Institute, www.securityprocedure.com/comparison-between-cobit-itil-and-iso-27001, Trabajo final de Graduación del Sistema de Estudios de Posgrado de la UNED perteneciente a Gabriela Garita, Kattia González y Lisette Ureña, http://helkyncoello.wordpress.com/2008/12/08/itil-cobit-cmmi-pmbok-como-integrar-y-adoptar-los-estandares-para-un-buen-gobierno-de-ti/

Tarea #1

Los tres errores que puedo anotar están basados en la experiencia con el proyecto de Automatización del Proceso de Ventas, que se llevó a cabo en UNIMAR (división comercial del Grupo Numar), con el propósito de aumentar la cobertura directa a clientes detallistas sin incrementar la planilla del departamento de Operaciones, específicamente en las área de Facturación, Control de Inventarios y Bodega.  Este fue el primer proyecto que me correspondió dirigir, y del cual obtuve grandes experiencias que logré aplicar para los siguientes.  A continuación el detalle:

1. No contábamos con el patrocinador adecuado.  En el desarrollo de la automatización del proceso de ventas, nuestro patrocinador principal era el Gerente de Operaciones, aunque también estaban involucradas las Gerencias de Ventas y la Gerencia General.  Sin embargo, yo dependía directamente da la Gerencia de Operaciones, que a fin de cuentas era una de las mayores beneficiadas con la puesta en marcha del proyecto. 

Durante el proceso de planeación y definición del proyecto, se dieron 3 cambios en la Gerencia de Operaciones, ya que por diversas razones, el Gerente que inició con el proyecto fue pasado a otra posición, el que lo sustituyó duró 15 días en el cargo y luego llegó ya el definitivo, después de algunas semanas con el puesto en el vacío mientras se designaba al candidato ideal.  Esto nos produjo que la persona que al final quedó en la Gerencia, no estuviera 100% involucrada con el proyecto, ya que desconocía todos los pormenores del mismo, y aún cuando sabía la importancia de llevar a cabo la implementación, su prioridad fue asumir el día a día del departamento antes que enterarse o involucrarse más con el proyecto.  Dado esto, muchas veces no contábamos con los recursos humanos requeridos en el momento necesario, pues eran asignados a sus labores operativas que eran “más urgentes”; al momento de hacer las pruebas con las primeras rutas, no estuvo de acuerdo con las rutas elegidas, las cuales habían sido definidas así al inicio en conjunto con el área de Ventas por cuestiones estratégicas (tanto por el tipo de ruta como por la personalidad del vendedor, que mostraba mayor apertura con los cambios propuestos).   En fin, tuvimos una serie de contratiempos al no tener desde el inicio el patrocinador adecuado, que se involucrara con el proyecto, que le doliera la piedra en el zapato con los problemas que se fueron presentando y más bien fue una especie de “obstáculo” en vez de un “facilitador”, muy a pesar de su buena voluntad y su apertura a la implementación.

 

Este aspecto fue radicalmente diferente cuando asumimos el proyecto de Apertura de los Centros Regionales de Distribución, en el cual el Gerente sí estuvo involucrado desde el inicio y fue un gran bastión para la finalización exitosa del proyecto, aportando sus conocimientos y experiencia, abogando ante la Gerencia General cuando fue necesario aumentar la inversión y poniendo a disposición la gente que se necesitaba para llevarlo a cabo en el tiempo requerido.

Siento que aunque en el primer proyecto no fue la situación ideal, era inevitable dado el momento que atravesaba la empresa en aquella época y la única forma de haberlo solucionado era que ese proyecto hubiese estado bajo la Gerencia General y no bajo la de Operaciones.  Sin embargo, por su naturaleza, era necesario que fuera tal y como se definió en principio, aunque era imposible prever los cambios de dirección que se presentaron.

Al final fue un proyecto exitoso, pues se logró pasar de atender 2.300 clientes a más de 8.500 manteniendo el mismo equipo humano en el departamento de Facturación, de Inventarios y de Bodegas, además de toda la enseñanza que nos dejó como empresa y a los departamentos involucrados (Sistemas, Ventas, Operaciones, etc.)

2. Intentamos hacer demasiado.  El tratar de complacer a varios clientes a la vez con un solo producto, haciendo cambios sobre la marcha, fue un arma de doble filo.  A pesar de tener definido claramente el alcance del proyecto, que inicialmente sería solo una aplicación para la toma de pedidos, la Gerencia General, las Gerencias de Ventas y la de Mercadeo fueron solicitando diferentes agregados a la aplicación original, pues cada uno fue determinado, en el camino, nuevas necesidades que querían fueran cubiertas con esta nueva opción.  Caímos en la trampa de ir diciendo sí a todas, lo cual generó que esta se hiciera cada vez más “pesada” y que se incluyeran módulos sin haber terminado el original y haberlo dejado listo para la calle. 

Evidentemente esto fue generando atrasos en las fechas de entrega, así como la molestia de nuestro proveedor por los constantes cambios y agregados no previstos inicialmente.

Considero que dada la magnitud que tomó el proyecto con estos nuevos requerimientos, debió hacerse por etapas y no queriendo sacar todo de una sola vez. Debimos habernos dedicado a sacar un módulo a la vez, estableciendo prioridades de acuerdo con su impacto en la parte operativa y su valor agregado al proceso de venta como tal, lo que habría contribuido no solo a que cada módulo fuera diseñado con más atención a los detalles sino también a que la aceptación por parte de la fuerza de ventas fuera más fácil y natural y no a como ocurrió, cuando se sintieron abrumados al tener que aprender no solo a usar un dispositivo que era totalmente nuevo para la mayoría, sino a manejar módulos de inventarios, de promociones, de controles a los clientes, etc. además del de ventas propiamente.

Esta lección fue bien aprovechada con el proyecto de los Centros Regionales, ya que dividimos las tareas en etapas para cada uno de los 5 centros y no iniciábamos una etapa nueva hasta no estar seguros de que la anterior estaba ya concluida.  De igual forma, nos dedicamos a cada centro individualmente, pues aunque en todos había que hacer las mismas tareas, no era siempre igual, de acuerdo a la ubicación geográfica, la cantidad de vendedores y clientes asignados, la capacitación que debía recibir cada administrador, las pruebas de conexión remota a los sistemas, etc.

3. Tropezamos en la fecha de conclusión.  Ligado al punto anterior de los agregados sobre la marcha, se fue corriendo la fecha de entrega definida originalmente para las primeras pruebas en calle del producto final y, curiosamente, quienes habían provocado los cambios que generaron el atraso, fueron los mismos que reclamaron más por el incumplimiento con la fecha de entrega. 

Dados los cambios, los tiempos asignados a la etapa del desarrollo de la aplicación, las pruebas internas de interfaces y transmisión remota, así como la capacitación a los vendedores tuvieron variaciones significativas, conllevando lógicamente a que la entrega del producto final tampoco se ajustara a la fecha prevista.

La falta de experiencia y la presión por la urgencia de sacar el producto a la calle contribuyeron en mucho a que las fechas límite tal vez no fueran muy realistas y si a esto le sumamos los atrasos generados por los cambios, era evidente que no se podría cumplir con la fecha propuesta.  Esto generó mucha tensión en el equipo, sobre todo porque se tenía muy claro el costo que implicaba el no salir con la aplicación para las fechas definidas, y al final repercutió en la etapa de pruebas, ya que tuvo que acortarse el tiempo destinado para ellas y dejar que muchos de los errores ocurrieran ya “en vivo” y buscarles solución dentro del proceso operativo ya en marcha.  De igual forma, en muchos casos la capacitación no fue la más adecuada, ya que no todos los vendedores asimilaron la información de la mejor manera durante el período de aprendizaje, y se tuvo que invertir más tiempo con algunos de ellos de forma individual para lograr su asimilación.

Para el siguiente proyecto, tratamos de manejar fechas más apropiadas, dejando tiempos “extra” en algunas de las tareas para evitar correr a última hora, y aunque siempre se debieron hacer algunos ajustes, estos fueron por situaciones totalmente fuera de control, como por ejemplo que las líneas de comunicación no fueron instaladas en la fecha que el ICE nos diera originalmente y esto provocó que las pruebas de conexión no pudieran realizarse en la fecha propuesta.

Como anoté arriba, este proyecto fue muy enriquecedor, tanto para la empresa como para los involucrados, no solo porque fue exitoso al cumplir los objetivos propuestos y en algunos casos más allá, sino por la cantidad de enseñanzas y experiencias que obtuvimos los que estuvimos involucrados en él y que pudimos aplicar para los proyectos futuros.  Se conformó un gran equipo de trabajo, que logró compenetrarse muy bien a pesar de ser de áreas muy distintas y esto generó una gran colaboración y fluidez en los procesos, no solo en los otros proyectos desarrollados, sino en la operación diaria de la empresa.