Christian A. Estay-Niculcar's research blog

Espacio de reflexión personal dedicado a la investigación aplicada cuando se vincula la ciencia proyectual con la disciplina informática, y se aplican al desarrollo de las personas y de la gestión empresarial.

Proyecto de Investigación-Acción en Sistemas de Información: Caso (1/3): Análisis Retrospectivo

1. INTRODUCCIÓN

El propósito de este post es mostrar los análisis y resultados obtenidos de aplicar procesos de gestión de proyectos de Investigación-Acción en Sistemas de Información (IA-SI) de forma retrospectiva a un caso tomado de la literatura. Este tipo de análisis sirvió para validar resultados con relativa seguridad sin afectar una situación real.

Así, en la sección 2 se introduce el caso y se describe lo que se entiende por análisis retrospectivo. La sección 3 presenta los problemas reportados en el caso estudiado. La sección 4 relaciona cada problema con las áreas de problemas como paso previo al uso de las prácticas de gestión de IA-SI. La sección 5 presenta la potencial solución con prácticas de gestión de proyectos para IA-SI.

Finalmente, la sección 6 realiza una recapitulación, para terminar con las referencias bibliográficas citadas en el post.

2. COMENTARIOS ACERCA DE ESTE ANÁLISIS RETROSPECTIVO

Para profundizar en problemas concretos y observar el incremento de rigurosidad, tomamos el estudio de Davison y Vogel (2000) sobre el uso de GSS (Group Support Systems) en un proyecto de mejora con reingeniería de una empresa en Hong Kong llamada Zeta. Se escoge por ser un artículo que presenta con un buen nivel de detalle y bastantes antecedentes cinco problemas manifestados al usar IA-SI.

Se le llama retrospectivo en el sentido que es el estudio de una experiencia pasada. Como tal permite hacer un estudio exhaustivo de la propuesta dentro de un marco controlado y ajeno a las propias experiencias (investigadores australianos trabajando en Hong Kong).

Robert Davison (2000), uno de los autores del estudio, en comunicación personal ha mostrado su conformidad con el trabajo realizado y sobre la validez de la propuesta como medio para solucionar o minimizar los problemas con una gestión de proyectos para IA-SI. Además, que sus comentarios han servido para enriquecer la propuesta. Sintiéndose conforme con el análisis de los cuatro primeros problemas, para el quinto señala que hay más información no mostrada en el artículo revisado planteando los riesgos de un análisis de textos.

Esto último es reportado por la literatura cuando se hace análisis de textos (Hodder, 1994). Sin embargo, para los fines no historicistas del análisis que se hace, es decir, solamente interesaba mostrar la aplicabilidad de una propuesta a un conjunto de datos disponibles y no en exponer los errores u omisiones de un grupo de investigadores, ya que es evidente la potencial falta de mayor evidencia que justifique o no, lo reportado.

En este sentido, el análisis retrospectivo es justificable, tal como se sugiere en determinados estudios de metaetnografía, cuando se hace etnografía a partir de textos o experiencias documentadas de autores y no hay manera de incrementar las evidencias que balanceen opiniones con más datos (Noblit y Hare, 1988).

3. LOS PROBLEMAS A ESTUDIAR

En el artículo de Davison y Vogel (2000) se mencionan y describen cinco problemas (ibid, pp. 11-12):

  • “chargeable time” o ‘carga de tiempo’;
  • “empowerment” o ‘falta de poder’;
  • “misappropriation of anonymity” o ‘pérdida del anonimato’;
  • “conflict between CIO and researcher” o ‘conflicto CIO-investigador’; y,
  • “data quality” o ‘calidad de los datos’.

Cada uno de estos problemas se comenta a continuación. Luego se hará un comentario de la situación en general.

3.1. PROBLEMA 1: ‘CARGA DE TIEMPO’

Un factor de desmotivación en los participantes fue la falta de tiempo que tenían para dedicar al proyecto (“A key demotivator for the team’s participation was that they could not charge the time so spent to any account”, ibid, p. 10). Esto se refleja claramente en dos cosas.

  • Por una parte, el sistema de asignación de tiempo que la empresa asignaba a los empleados en el caso del proyecto de Investigación-Acción no fue efectivo (“the time team members spent on the project was not chargeable”, ibid, p. 10, observación del investigador,), De hecho, esta falta de consideración se percibió como una actitud de poca seriedad hacia el proyecto de mejora por parte de los participantes.
  • Por otra parte, el CIO reflejaba su falta de interés hacia la asignación de tiempo, refiriéndose en los siguientes términos: “For me personally, chargeable hours are not of importance [ … ] Although   knew that chargeability is used as a measure of performance for client service providers, I did not fully appreciate the influence that it has” (ibid, p. 13).

3.2. PROBLEMA 2: ‘FALTA DE PODER’

Este problema se relaciona con una más alta o sencillamente la ausencia de una cuota de poder para llevar superar la relación entre el CIO, y los practicantes y el investigador. El CIO no notaba la falta de interés por el trabajo de mejorar el proceso de negocio y, sin embargo, asignaba pesadas lecturas sobre reingeniería que quedaban finalmente sin leer. Entre las razones argumentadas para esta falta de interés era que el proceso de reingeniería era materia del CIO y, además, los participantes no estaban voluntariamente asignados al proyecto.

Lo anterior aparece reflejado en expresiones como: “The CIO clearly identified the need to empower the team members and entrust them with the responsibility for re-engineering the […] process. However, he did not explicitly communicate his rationality to them, nor could he appreciate their lack of interest in solving the task” (ibid, p. 10).

Esta complicada situación era superada finalmente, con una intimidación por parte del CIO y, con conformidad por parte de los participantes.

3.3. PROBLEMA 3: ‘PÉRDIDA DEL ANONIMATO’

El CIO generaba ideas de forma anónima creyendo que de esta manera podía provocar a los miembros del equipo (“CIO misappropriated the anonymity of the GSS, projecting large numbers of his own ideas without their authorship being positively attributable”, ibid, p. 12). No obstante los practicantes no se sentían gratos con esta falta de anonimato, si bien se reconocía la mano del CIO por detrás de tales mensajes anónimos.

Un elemento que agravaba esta actitud era que el CIO no expresaba todas sus ideas en público o en abierto debate, prefiriendo las discusiones privadas. Además, no existían moderadores neutrales dada la presión del CIO sobre el investigador (ver problema 4).

El imperativo del anonimato y la necesidad de expresar públicamente las ideas, era reflejo de las incongruencias entre una “culture of cautiousness hampered” por Zeta (ibid, p. 13) sobre la información y una herramienta GSS que permitía la comunicación anónima, pero con un CIO actuando como provocador anónimo.

El problema real era no comprender la importancia del anonimato para motivar la discusión y la comunicación libre.

3.4. PROBLEMA 4: ‘CONFLICTO CIO-INVESTIGADOR’

El rol público inicial del investigador fue de un consultor técnico, para asistir en el uso adecuado de la herramienta GSS en el contexto del proyecto de reingeniería. Sin embargo, el investigador “intervened in a heated debate between the CIO and team members to suggest that some cultural confusion might underlie the discussion and its lack of progress” (ibid, p. 13). Esta intervención surgió cuando, ante un debate entre el CIO y los miembros del equipo, señaló algunas confusiones subyacentes al debate, no obstante, “The CIO took grave offence at his intervention” (ibid, p. 13), mostrándose molesto, ante lo cual manifestó al investigador que tuviese mayor cuidado sobre su alineación con las partes del proyecto.

El problema era la falta de un claro posicionamiento y rol del investigador frente al CIO y los practicantes.

Luego de la desafortunada intervención del investigador frente al CIO, el investigador tomó un rol más activo frente al estilo de liderazgo del CIO y, además, que la herramienta GSS no estaba aportando mucha eficiencia al proceso. El investigador se dedicó a imbuir en los encuentros un estilo de comunicación más amistoso, aprovechar las reuniones de mejor manera, intentar reducir la influencia del CIO e, identificar oportunidades de aprendizaje para los miembros del equipo.

3.5. PROBLEMA 5: ‘CALIDAD DE LOS DATOS’

El investigador usó un instrumento de recogida de datos tipo lista de chequeo, que permitía detectar percepciones relativas a los encuentros de los participantes, calidad de la discusión y, efectos de la comunicación, eficiencia y trabajo en equipo. Sin embargo, en el tercer encuentro, “the CIO criticized the instrument design, arguing that it would be more useful to make comparative measurements from week to week. In consequence, it [the instrument] was redesigned” (ibid, p. 13). Pero el problema no era el CIO, sino la rigidez en el uso de instrumentos de investigación.

4. RESOLUCIÓN CON PROCESOS DE GESTIÓN DE PROYECTOS

A la luz de lo comentado en cada problema, se pueden sugerir las siguientes líneas de acción desde gestión de proyectos haciendo un análisis previo y clasificatorio según las áreas de problemas. Los problemas a estudiar se relacionan con las áreas de problemas según muestra la Tabla 1.

Tabla 1: Relación de problemas estudiados con áreas de problemas - (c) Christian A. Estay-Niculcat

Tabla 1: Relación de problemas estudiados con áreas de problemas – (c) Christian A. Estay-Niculcar

4.1. PROBLEMA 1: ‘CARGA DE TIEMPO’

La carga de tiempo es un problema metodológico que presenta dos dimensiones:

  • la disponibilidad del personal para participar del proyecto; y,
  • el compromiso de los participantes seleccionados y la organización.

Para la primera dimensión, el problema de disponibilidad fue motivado por dos fallas, que afectaban las agendas de los practicantes. Esto se notaba en:

  • presiones en las reuniones (“Team members were informed in advance of forthcoming activities to give them preparation time; they were also reminded to meet task deadlines”, ibid, p. 8); y,
  • discontinuidades en la investigación (“‘timetable’ was frequently interrupted, with up to 6 weeks separating some meetings […]”, ibid, p. 8).

Por otra parte, la disponibilidad de personal se haya relacionada con el interés e intención de los participantes por el proyecto de Investigación-Acción (“process was a complex task involving actors from different departments with differing vested interests”, ibid, p. 6).

Mayor o menor interés, o intencionalidad deseada, de una u otra manera, hacen o no soportable el trabajo asignado y las jornadas de reuniones, y la predisposición a superar la carga de trabajo. Con la información aportada en el documento revisado, no se puede saber en que medida ocurría, no obstante el investigador lo consideró relevante (“[…] it was desirable that the team members should play as active a role in the project as possible, as their insights, and those of their colleagues, should be relevant to the re-engineering process, ibid, p. 6), con el fin de conseguir mayor participación, “participation would increase the likelihood that the new client billing process would be implemented effectively in all departments” (ibid, p. 7).

La segunda dimensión se relaciona con el problema 2, ya que era parte de la cultura de Zeta el poco apoyo institucional, una “attitude stemmed in part from Zeta’s organizational culture, which did not encourage, let alone reward, innovation or working outside’s immediate task environment” (p. 10).

4.2. PROBLEMA 2: ‘FALTA DE PODER’

Este problema es metodológico debido a la ausencia de apoyo organizacional, lo que se refleja en:

  • falta de apoyo de la gestión senior pues los “senior partners ostensibly approved the initiation of the project, yet failed to give the team members any overt recognition of the value of their work, and it is certain that the system of chargeable time mitigated against their involvement; that the firm and the CIO failed to take account of this when the project was approved was short-sighted at best. At the end of the project, the project’s executives sponsor expressed some appreciation for the work that the team had accomplished [ … ]” (ibid, p. 14); y,
  • falta de apoyo de los mismos participantes, pues “Indeed, they appeared to have little vested interest in, o motivation for, the problem they had been assigned to tackle […]” (ibid, p. 11).

Esto último generaba problemas de desmotivación reflejado en: Desmotivación que solamente se superaba con una característica actuación por mandato.

4.3. PROBLEMA 3: ‘PÉRDIDA DEL ANONIMATO’

Este es un problema ligado a la poca claridad del rol del CIO y por ello vinculado a los problemas del área de documentación.

  • Por una parte, el CIO provocaba a los participantes enviándoles mensajes con el fin de “to encourage participation, with all team members having a fair go at contributing to the processes, yet he also felt the occasional need to be autocratic to ensure that thing did get done” (ibid, p. 11).
  • Por otra parte, el anonimato era un problema asociado a la sicología de los participantes, quienes no veían ninguna importancia a proveer ideas. De hecho, para ellos su participación en el proyecto no la sentían de beneficio a sus carreras. Esto se relacionaba con el problema de carga de tiempo.

Lo anterior finalmente se debía a:

  • la “lack of interest was augmented by the CIO’s failure either to communicate why the review process was important or to allocate a sufficiently high priority to the task himself” (ibid, p. 11); y,
  • la confusión que producía el CIO debido a que él “referred to business process re-engineering on a number of occasions, but did not communicate this effectively to the other team members” (ibid, p. 4).

Durante el proyecto se olvidaron algunas reglas esenciales del anonimato como parte del juego de conseguir los resultados de trabajo que surgen en las instancias de ejecución del proyecto. Reglas asociadas tanto a los compromisos del proyecto como a la misma definición de roles.

4.4. PROBLEMA 4: ‘CONFLICTO CIO-INVESTIGADOR’

Este problema se relaciona con las áreas de ‘ética y valores’ y ‘metodología’ porque involucra compromiso del investigador con el problema y, su rol y relaciones con la organización y el CIO.

El rol poco claro se nota en frases como: “No formal protocol governing my involvement was specified, although senior partners at Zeta were informed of my presence” (ibid, p. 5). Además, su presencia estaba dominada por una percepción técnica debido a que “The CIO initially nominated me as a technical facilitator” (ibid, p. 5), mientras “Ventana Corporation authorized me to install the GSS software at Zeta for the duration of the project at no charge, provided that I supervised the use of the software and subsequently shared research findings with Ventana” (ibid, p. 5).

De tal nivel era la falta de compromiso hacia la organización que “I was the sole facilitator at Zeta, but I was neither bound by any formal contract [ … ], which restricted to this one project; furthermore, I was never requested to deliver a solution that would support any particular viewpoint” (ibid, p. 5).

Estas carencias eran de tal envergadura que de nada sirvió que “in conjunction with the CIO, I initiated planning for the project” (ibid, p. 8). Ni que ésto fuese de alguna ayuda (“helped me to understand the CIO’s objectives and the project’s limitations as imposed by organizational structures”, ibid, p. 8).

Lo único que se conseguía con esta falta de compromiso era que el CIO veía al investigador como un ‘chico’ sin contrato asistiéndoles técnicamente en el uso de un software. Por suerte, con el tiempo, el investigador “successfully persuading the CIO to relinquish some of his responsibilities” (ibid, p. 5), con lo cual adquirió un rol más concreto y activo de ‘action-researcher’: “When I changed my role [ … ] attempting to increase the involvement of participants and decrease the normative influence of the CIO [ … ] “ (p. 15).

De esto puede extraerse una lección y es que el cliente o quien financia el proyecto debe quedar bien definido su rol durante la conformación de los participantes en el proyecto. Además, fijar el rol del investigador, es una actividad del proceso de iniciación (5.1) que queda estipulada en el plan del proyecto.

4.5. PROBLEMA 5: ‘CALIDAD DE LOS DATOS’

Este problema se relaciona con el área de ‘cambio epistemológico’ en el sentido que el investigador no consideró durante el proceso de investigación, la flexibilidad. De hecho, él mismo la expone como relevante.

La ciega confianza del investigador en el método se refleja en expresiones como: “The fact that these did not happen [ (CIO re-engineer the process himself) ], despite the CIO’s wry comment that the team members probably autodeleted his email, testifies to the robustness of a methodology that supports flexibility, continuous intervention and appropriate change” (ibid, p. 14).

Sin embargo, la práctica rutinaria mostró lo errado de tal pensamiento, cuando el investigador señala que “although the CIO agreed that the questionnaire should be completed after each meeting, this was confounded by team members who refused to do so on a number of occasions, with data collected only in the first, second, fourth, fifth and seventh cycles” (ibid, p. 9), mostrando que el medio de capturar datos no era robusto frente a la variabilidad de caracteres, interpretación de las cosas y comprensión de la realidad de la naturaleza humana.

El problema fue olvidar la flexibilidad o no percibirla, la cual solamente se vio cuando el CIO planteó la necesidad de cambiar o readecuar el instrumento de captura de datos. Además, esto refleja que los instrumentos de investigación en uso funcionan en muchos casos en condiciones ideales.

Al final el investigador tuvo que “wrote up a report describing the discussion and the agreements reached, distributing this to al the members” (ibid, p. 6), buscando enriquecer los datos recogidos con sus propias opiniones surgidas de los encuentros o reuniones del trabajo.

5. RESOLUCIÓN CON PROCESOS DE GESTIÓN DE PROYECTOS DE INVESTIGACIÓNACCIÓN EN SISTEMAS DE INFORMACIÓN

A partir de los comentarios y sugerencias previas, es posible sugerir las siguientes soluciones a los problemas.

5.1. PROBLEMA 1: ‘CARGA DE TIEMPO’

Una solución posible al problema 1 vendría desde el proceso 9.2 (‘Staff Acquisition’), desde el cual se garantiza la disponibilidad de los trabajadores, según sus jornadas de trabajo, intereses e intenciones. Si así fuese posible, los miembros de Zeta habrían sido seleccionados adecuadamente y definido su rol claramente.

En el mismo proceso 9.2 se pide el compromiso de disponibilidad del personal, reduciendo el problema de carga de tiempo que habría sido un tema sujeto a compromisos laborales. Además, existe el compromiso organizacional que se genera en el proceso 5.1. (‘Initiation’), donde se pide el apoyo de la organización al proyecto y no solamente del cliente, en este caso el CIO, en orden a garantizar organizacionalmente el poder y disponibilidad solicitado para los participantes.

En su conjunto todo esto aminora el impacto del problema de carga de tiempo y además ayuda a clarificar la distribución del trabajo durante la ejecución del proyecto (lo que en los procesos 6.1 ‘Activity Definition’, 6.2 ‘Activity Sequencing’ y 6.3 ‘Activity Duration Estimating’).

5.2. PROBLEMA 2: ‘FALTA DE PODER’

La solución tentativa al problema 2 es similar a la del problema 1, buscando el compromiso de participación de todos los actores involucrados. En general, el investigador en este proceso busca asignar y balancear el apoyo organizacional de la organización a los participantes y el proyecto, con un adecuado fortalecimiento del poder para que los participantes tomen decisiones y actúen.

Esto se puede conseguir:

  • con un compromiso de los participantes que puede obtenerse y formalizarse en el proceso 9.2 cuando se asignan roles y responsabilidades; y,
  • con un compromiso en el proceso 5.1 (‘Initiation’) y formalizado con el documento de justificación del proyecto (‘project charter’) fundado en el proceso 5.2 (‘Scope planning’) donde la organización garantiza la participación de la gente y les da apoyo para tomar decisiones y actuar.

5.3. PROBLEMA 3: ‘PÉRDIDA DEL ANONIMATO’

Este problema se puede atender cuando en el proceso de selección del personal se asigna el rol y responsabilidad de cada participante del proyecto, seguido del compromiso organizacional de que podrán cumplir lo que se espera de ellos. De esta manera una solución tentativa para reducir este problema 3 proviene del proceso 10.2 (‘Information Distribution’) que distribuye información según los criterios de comunicación definidos en el proceso 10.1 (‘Communications Planning’).

Más aún, el proceso 10.1 es el proceso de generación del plan de comunicaciones y por tanto el sitio donde detectar y clarificar potenciales errores o fallas de comunicación, sus soluciones, canales para capturar y diseminar datos (dando relevancia al anonimato) y, definiendo el vocabulario a usar.

Por otra parte, el proceso 9.3 (‘ Team Development ‘) es un camino para mantener un nivel de motivación alto mediante técnicas y prácticas de gestión y de recursos humanos. En este mismo proceso, incluso el investigador tiene la posibilidad de dar importancia o promover el anonimato, recolocando a los participantes dentro de la estructura del grupo de Investigación.-Acción para promover su participación según motivaciones de los practicantes pero intentando beneficiar al proyecto.

5.4. PROBLEMA 4: ‘CONFLICTO CIO-INVESTIGADOR’

El problema 4 puede abordarse con proceso de iniciación del proyecto (5.1). En este proceso la relación entre el investigador con la organización y los actores organizacionales son estipulados en el documento de justificación del proyecto (‘project charter’). Más aún, los roles son clarificadores y el investigador debe aclarar su posición y lo que significa Investigación-Acción. Esto último en particular habría ayudado a evitar los conflictos entre investigador y CIO, por ejemplo.

En los procesos 9.1 y 9.2, roles, intereses, responsabilidades e intenciones se pueden aclarar. En este proceso el investigador puede planear acciones para regular cualquier desviación de intereses e intenciones, propias o ajenas. Por ejemplo para manejar al CIO, quien “had recently arrived in Hong Kong from UK with degrees in information systems and statistics […]” (ibid, p. 5) y estaba interesado en aplicar sus nuevos conocimientos.

5.5. PROBLEMA 5: ‘CALIDAD DE LOS DATOS’

Metodológicamente este problema puede abordarse desde el proceso 10.1 (‘Communications Planning’), donde se seleccionan e indican los medios para capturar los datos según las condiciones organizacionales y las características de los participantes. Además, se proveen inspecciones a lo largo del proyecto para saber identificar la bondad de las técnicas de captura de datos, las cuales pueden ser refutadas con juicios expertos en los procesos 4.2 (‘Project Plan Execution’), 4.3 (‘Overal Change Control’), 5.4 (‘Scope Verification’) y 5.5 (‘Scope Change Control’).

Por último, es principio de Investigación-Acción la flexibilidad para cambiar todo lo que sea necesario, especialmente debido a la continua adaptación de situaciones y escenarios donde se investiga. Al reconocer este principio y las definiciones que se consiguen en el proceso 10.1 (‘Communications Planning’), la robustez de los datos se ve apoyada, incluyendo, además, una generación constante de datos del estudio, sujetos a inspecciones por parte de los participantes y a juicio experto.

6. RECAPITULACIÓN

Se ha mostrado la aplicación de la propuesta de una gestión del Proyecto de IA-SI mediante un análisis retrospectivo. Esto ha permitido mostrar que simples prácticas de gestión sirven para resolver los problemas reportados de IA-SI, no obstante, cuando tales prácticas son especializadas para IA-SI, resultan ser más efectivas.

Este tipo de análisis, desarrollado en estadios iniciales del trabajo de tesis, permitieron mostrar la validez de la propuesta y verificar los primeros intentos de una gestión del Proyecto de IA-SI.

7. REFERENCIAS BIBLIOGRÁFICAS

  • Davison, Robert. (2000) [Comunicación personal] (omitida por ser un correo personal).
  • Davison, Robert; y, Vogel, Doug. (2000). Group support systems in Hong Kong: an action research project. Information Systems Journal, 10(1):3-20. January.
  • Hodder, Ian. (1994). The Interpretation of Documents and Material Culture. En Denzin, N.; y, Lincoln, Y. Eds. (1994). Handbook of Qualitative Research. SAGE. 643 pp., pp. 393-402.
  • Noblit, George W.; y Hare, Dwight R. (1988). META-ETHNOGRAPHY. Synthesizing Qualitative Studies. Qualitative Research Methods Series, nº 11. SAGE. 88 pp.

__________________________

Post relacionados directamente

Viene de …

Artículos relacionados … / Related article …

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

CEO & Co-Founder de EstayConsulting – Consultoría Estratégica

Miembro de Red

//pagead2.googlesyndication.com/pagead/js/adsbygoogle.js (adsbygoogle = window.adsbygoogle || []).push({});

Categorías

A %d blogueros les gusta esto: