TEMA 4 DETERMINACION DE LA VIABILIDAD Y ADMINISTRACION DE LAS ACTIVIDADES DE ANALISIS Y DISEO

FUNDAMENTOS DEL PROYECTO

La iniciacin de proyectos, la determinacin de la factibilidad del proyecto, la calendarizacin del proyecto y la
administracin de las actividades y de los miembros del equipo para lograr productividad, son capacidades muy
importantes que debe dominar el analista. Como tales, son consideradas partes fundamentales del proyecto.
Un proyecto de sistemas comienza con problemas y oportunidades de mejora dentro de un negocio, que
frecuentemente se presentan conforme la organizacin se adapta a los cambios. Si es aprobado un proyecto se har
un estudio de sistemas completo. Las actividades del proyecto son calendarizadas mediante el uso de herramientas
tales como grficas de Grantt y PERT, para que el proyecto pueda ser realizado a tiempo.
INICIO DEL PROYECTO
Los proyectos de sistemas se inician por muchas razones. Las personas de los negocios sugieren proyectos de sistemas
por dos amplias razones: (1) para experimentar en problemas que les lleven por s mismos a soluciones de sistemas y
(2) para reconocer oportunidades y hacer mejoras mediante la actualizacin, alteracin o instalacin de nuevos
sistemas. Ambas situaciones pueden darse cuando la organizacin se adapta y enfrenta cambios naturales y
evolucionados.

PROBLEMAS DENTRO DE LA ORGANIZACIN

A los administradores no les agrada aceptar que sus organizaciones tienen problemas, y muchos menos hablar de ellos
con alguien externo. No obstante, los buenos administradores estn conscientes de que para mantener el negocio
funcionando a su ms alto potencial es imperativo que reconozcan los sntomas de los problemas o, en etapas ms
avanzadas, que los diagnostiquen y les hagan frente.
Los problemas surgen de diversas maneras. Una forma de averiguar que hay problemas y cmo se originaron, es
considerarlos como situaciones en las cuales ya no se alcanzan o nunca se han alcanzado las metas fijadas. La
retroalimentacin til pone de manifiesto la brecha existente entre el desempeo real y el que se pretende. De esta
manera, la retroalimentacin ayuda a resaltar los problemas.
En algunos casos, los problemas que requieren la atencin del analista de sistemas permanecen ocultos porque no se
realizan mediciones del desempeo. Los problemas (o sntomas de problemas) en procesos cuyos resultados son
visibles y que podran requerir la
ayuda de un analista de sistemas incluyen errores excesivos y trabajo realizado con demasiada lentitud, incompleto,
incorrecto o que no se hace. Otros sntomas de problemas se vuelven evidentes cuando los individuos no cumplen las
metas de desempeo establecidas.
Los cambios en el comportamiento de los empleados como una elevada tasa de ausentismo,
creciente descontento en el trabajo o una alta rotacin de trabajadores deben alertar a los administradores sobre la
existencia de problemas potenciales. Cualquiera de estos cambios,
solos o en combinacin, constituyen una razn de peso para solicitar la ayuda de un analista de sistemas.
Aunque los problemas como los recin descritos ocurren al interior de las organizaciones, la retroalimentacin sobre
qu tan bien cumple la organizacin sus metas podra llegar del exterior, en forma de quejas o sugerencias por parte
de clientes, distribuidores o proveedores, y prdida o reduccin inesperada de ventas. Esta retroalimentacin del
entorno externo es sumamente importante y no debe ignorarse.
En la figura 3.1 se ofrece un resumen de sntomas de problemas y de tcnicas tiles para la deteccin de los mismos.
Advierta que la revisin de resultados, la observacin del comportamiento de los empleados y la atencin a la
retroalimentacin proveniente de fuentes externas son valiosas para la deteccin de problemas. Como se discuti en
el captulo 1, al responder a los problemas que se presentan en una organizacin, el analista de sistemas desempea
los roles de consultor, experto en soporte tcnico y agente de cambio.
Como cabra esperar, los roles del analista de sistemas cambian sutilmente cuando se inician los proyectos, porque la
atencin se concentra en las oportunidades de mejora ms que en la necesidad de solucionar problemas.




Para identificar problemas Busque estos signos especficos
Revise los resultados contra los criterios
de desempeo
Demasiados errores
Trabajo realizado con lentitud
Trabajo realizado de manera incorrecta
Trabajo incompleto
Trabajo no realizado

Observe el comportamiento de los empleados

Elevado ausentismo
o Creciente descontento
o Alta rotacin de trabajadores
Ponga atencin en la retroalimentacin externa de: Quejas
Distribuidores Sugerencias de mejora
Clientes Prdida de ventas
Proveedores Reduccin de ventas

Figura 3.1

SELECCIN DE PROYECTOS
Los proyectos vienen de muchas fuentes diferentes y por muchas razones. No todos deben ser seleccionados para un
estudio posterior. Hay que considerar la motivacin que impulsa la propuesta del proyecto. Es necesario asegurarse de
que el proyecto bajo consideracin no este siendo propuesto simplemente para mejorar la propia reputacin no est
siendo propuesto simplemente para mejorar la propia reputacin poltica, o poder de la persona o grupo que lo
propone, debido a que hay mucha probabilidad de que el proyecto est concebido inadecuadamente y hasta que sea
mal aceptado.
No olvide que los diversos sistemas de la organizacin estn interrelacionados y son interdependientes, por lo que un
cambio a un subsistema puede afectar a todos los dems. Incluso aunque los tomadores de decisin directamente
involucrados ponen, a fin de cuentas, las fronteras para el proyecto del sistema, un proyecto de sistema no puede ser
contemplado o seleccionado en forma aislada del resto de la organizacin.
Mas all de estas consideraciones generales estn los cinco criterios especficos para la seleccin de proyectos que se
listan en la figura 3.2. el primero, y ms importante, es el respaldo de la administracin. No se puede lograr
absolutamente nada sin la aprobacin de las personas que, a final de cuentas, pagarn la cuenta.


Figura 3.2
El respaldo de los directivos de la organizacin.
Un periodo adecuado de compromiso para terminar el proyecto
La posibilidad de mejorar la consecucin de las metas organizacionales.
Factibilidad en cuanto a recursos para el analista de sistemas y la
organizacin.
La rentabilidad del proyecto en comparacin con otras formas en que la
organizacin podra invertir sus recursos.
Esto no significa que no se tenga la influencia para dirigir el proyecto o que no puedan ser incluidas otras personas
aparte de los administradores. Sin embargo, el respaldo de la administracin es esencial.
Otro criterio importante para la seleccin del proyecto incluye la temporizacin para usted mismo y la organizacin.
Pregntese usted, y a los dems involucrados, si el negocio es actualmente capaz de hacer el compromiso de tiempo
para la instalacin de nuevos sistemas o la mejora de los existentes.
Tambin usted debe ser capaz de comprometer todo o parte de su tiempo por la duracin del proyecto.
Un tercer criterio es la posibilidad de mejorar la obtencin de los objetivos de la organizacin. El proyecto debe poner
a la organizacin hacia su destino y no desalentarla de sus objetivos finales. Un cuarto criterio es la seleccin de un
proyecto que sea posible llevar a la prctica, de acuerdo con los recursos y capacidades propias as experiencia propia
y se debe ser capaz de reconocerlo.
Por ltimo, se deber llegar a un acuerdo bsico con la organizacin acerca del valor del proyecto de sistema ante
cualquier otro proyecto posible que est siendo considerando. Recuerde que cuando un negocio se compromete a un
proyecto est comprometiendo recursos que de esta forma ya no se encuentran disponibles para otros proyectos. Es
til ver a todos los proyectos posibles en competencia por los recursos del tiempo, dinero y gente del negocio.
DETERMINACIN DE LA FACTIBILIDAD
Para los proyectos de sistemas la factibilidad es valorada en tres formas principales: operacional, tcnica y
econmicamente. Un proyecto debe ser factible en las tres formas para merecer un desarrollo posterior, el estudio de
factibilidad no es un estudio de sistema completo. En vez de ello, se usa al estudio de factibilidad para recopilar datos
burdos para la administracin, para que a su vez les permitan tomar una decisin sobre si deben continuar con el
estudio de sistema.
Los datos para el estudio de factibilidad pueden ser recolectados por medio de entrevistas, estn directamente
relacionadas con el problema u oportunidad que est siendo sugerido. Aunque es importante atacar el problema
adecuado, no se debe gastar mucho tiempo haciendo estudios de factibilidad, debido a que muchos proyectos sern
solicitados y solamente unos cuantos debern ser ejecutados. El estudio debe estar altamente comprimido en el
tiempo, comprendiendo varias actividades en un pequeo lapso.
Definicin de objetos
La determinacin de factibilidad en general de un proyecto solicitado significa el encontrar cules son los objetivos
organizacionales, y luego determinar si el proyecto sirve para mover el negocio hacia sus objetivos en alguna forma.
Los objetivos del proyecto deben ser calificados por medio de entrevistas con la persona, grupo o departamento que lo
propone. Adems, tambin es til una revisin de los trabajos escritos que se relacionen con el proyecto solicitado.
Hay varios objetivos aceptables para los proyectos de sistemas que estos incluyen, pero no estn limitados, a:
1- Reducir errores y mejorar la precisin de los datos de entrada.
2- Reducir el costo de la salida del sistema mediante la agilizacin y eliminacin
de reportes duplicados o innecesarios.
3- Integrar los subsistemas del negocio.
4- Mejorar los servicios al cliente para ganar una posicin competitiva.
5- Acelerar la entrada.
6- Acortar el tiempo de procesamientos de datos.
7- Automatizar los procedimientos manuales para mejorarlos en alguna forma.
Tambin podemos decir que es inaceptable automatizar procedimientos manuales simplemente por automatizarlos, o
invertir en tecnologa nueva sin tomar en consideracin su contribucin verdadera para el logro de los objetivos de la
organizacin.
Determinacin de recursos
La determinacin de recursos para el estudio de factibilidad sigue el mismo patrn amplio tratado anteriormente, y
ser revisado y vuelto a evaluar cuando se encomiende el estudio del sistema formal. Los recursos sern tratados en
relacin con tres reas de factibilidad: tcnica, econmica y operacional.
Factibilidad tcnica: una gran parte de la determinacin de recursos tiene que ver con la valoracin de la factibilidad
tcnica. El analista debe encontrar si los recursos tcnicos actuales pueden ser mejorados o aadidos, en forma tal que
satisfaga la peticin bajo consideracin. Sin embargo, algunas veces las adiciones a los sistemas existentes son
costosas y no valen la pena, debido simplemente a que satisfacen las necesidades en forma ineficiente. Si los sistemas
existentes no pueden ser aadidos, la siguiente pregunta es si hay tecnologa en existencia para satisfacer las
especificaciones. La respuesta sobre si una tecnologa particular se encuentra disponible y es capaz de satisfacer las
peticiones del usuario es si, entonces se convierte en econmica.
Factibilidad econmica: La factibilidad econmica es la segunda parte de la determinacin de recursos. Los recursos
bsicos a considerar son: el tiempo propio y el equipo de sistemas, el costo de hacer un estudio de sistema completo,
el costo del tiempo de los empleados del negocio, el costo estimado de hardware y el costo del software y/o
desarrollos de software.
El negocio de que se trate debe ser capaz de hacer ver el valor de la inversin en su ponderacin antes de
comprometerse en un estudio de sistemas completo. Si los costos a corto plazo no son sobrepasados por las ganancias
a largo plazo, o no producen una reduccin inmediata en los costos de operacin, el sistema no es factible
econmicamente y el proyecto ya no debe continuar.
Factibilidad operacional: La factibilidad operacional depende de los recursos humanos disponibles para el proyecto, e
involucra proyectar si el sistema operar y ser usado una vez est instalado.
Si los usuarios estn casados virtualmente con el sistema presente, la resistencia ante la implementacin del nuevo
sistema ser fuerte. Las oportunidades de que alguna vez llegue a ser operacional son escasas.
Si los usuarios han expresado la necesidad de que un sistema que es operacional la mayor parte del tiempo tenga una
forma ms eficiente y accesible, si tiene mejor oportunidad de que el sistema solicitado llegue a ser utilizado.
En el momento de la determinacin de la factibilidad operacional requiere creatividad por parte del analista, que
permita que los usuarios sepan cuales interfaces son posibles y cuales satisfacern sus necesidades.
Evaluacin de la factibilidad: Es evidente que la evaluacin de la factibilidad de los proyectos de sistemas nunca es una
tarea fcil o bien definida. Lo que es ms, la factibilidad del proyecto no es una decisin a ser tomada por el analista
sino por la administracin. Las decisiones estn basadas en los datos de factibilidad recolectados en forma expresa y
profesional y presentados por el analista.
El analista necesita asegurarse que las tres reas de factibilidad, tcnica, econmica y operacional, sean atacadas en el
estudio preliminar. El estudio de un proyecto de sistemas solicitado debe ser logrado rpidamente, a fin de que los
recursos que se le dediquen sean mnimos, la informacin producida por el estudio sea slida y cualquier inters
existente en el proyecto se mantenga alto. Este es un estudio preliminar que precdela estudio del sistema, y debe ser
ejecutado en forma rpida y competente.
Aunque es laborioso, el estudio de la factibilidad vale la pena, y , a la larga, ahorra a los negocios y analistas gran
cantidad de tiempo y dinero.

PLANEACION Y CONTROL DE ACTIVIDADES
El anlisis y diseo de sistemas involucra muchos tipos diferentes de actividades que en
conjunto conforman un proyecto. El analista de sistemas debe manejar el proyecto con cuidado si desea que ste
tenga xito. La administracin de proyectos abarca las tareas generales de planeacin y control.
La planeacin incluye todas las actividades requeridas para seleccionar un equipo de anlisis de sistemas, asignar
miembros del equipo a proyectos adecuados, calcular el tiempo
necesario para realizar cada tarea y programar el proyecto de tal manera que las tareas se terminen a tiempo. El
control implica el uso de retroalimentacin para monitorear el proyecto, incluyendo la comparacin del plan original
del proyecto con su evolucin real. Adems, el control significa emprender las acciones apropiadas para agilizar o
reprogramar actividades para terminar en tiempo, a la vez que estimulen a los miembros del equipo a realizar el
trabajo de manera profesional.
CLCULO DEL TIEMPO REQUERIDO
La primera decisin del analista de sistemas es determinar el nivel de detalle necesario para definir las actividades. El
nivel ms bajo de detalle es el ciclo de vida del desarrollo de aplicaciones mismo, mientras que el extremo ms alto
consiste en incluir cada paso en detalle.
La respuesta ptima para la planeacin y la programacin se encuentra en algn punto medio.
Aqu es til un enfoque estructurado. En la figura 3.5 el analista de sistemas que comenz un proyecto dividi el
proceso en tres fases principales: anlisis, diseo e implementacin.
A continuacin, la fase de anlisis se divide a su vez en recopilacin de datos, anlisis del flujo de datos y de decisiones,
y preparacin de la propuesta. El diseo se divide en diseo de la captura de datos, diseo de la entrada y la salida, y
organizacin de datos. La fase de implementacin se divide en implementacin y evaluacin.
En pasos subsecuentes el analista de sistemas tiene que considerar cada una de estas tareas y dividirlas an ms para
que se realicen la planeacin y la programacin. La figura 3.6 muestra que la fase de anlisis se describe con ms
detalle. Por ejemplo, la recopilacin de datos se divide en cinco actividades, desde la realizacin de entrevistas hasta la
observacin
de las reacciones hacia el prototipo. Este proyecto especfico requiere anlisis del flujo de datos pero no anlisis de
decisiones, por lo tanto el analista de sistemas ha escrito "analizar
el flujo de datos" como nico paso en la fase intermedia. Por ltimo, la preparacin de la propuesta se ha dividido en
tres pasos: realizar anlisis de costos y beneficios, preparar la propuesta y presentar la propuesta.
Por supuesto, el analista de sistemas tiene la opcin de dividir an ms los pasos. Por ejemplo, podra especificar cada
una de las personas que se entrevistarn. El nivel de detalle necesario depende del proyecto, pero es importante que
todos los pasos crticos aparezcan en los planes.
Con frecuencia la parte ms difcil de la planeacin de un proyecto es el paso crucial de calcular el tiempo requerido
para terminar cada tarea o actividad. Cuando se les preguntan las razones de la tardanza en un proyecto especfico, los
miembros del equipo argumentan clculos errneos en la programacin que obstaculizan desde el principio el xito
del proyecto. Nada reemplaza a la experiencia al momento de calcular el tiempo requerido, y los analistas de sistemas
que han tenido la oportunidad de pasar por un periodo de aprendizaje son afortunados en este sentido.
Los encargados de la planeacin han intentado reducir la incertidumbre inherente en determinar los estimados de
tiempo proyectando estimados ms probables, pesimistas y optimistas
y aplicando a continuacin una frmula de ponderacin del promedio para determinar el tiempo esperado que tomar
una actividad. Sin embargo, este mtodo no es tan confiable.
Quiz la estrategia ms aconsejable para el analista de sistemas es apegarse a un enfoque estructurado para
identificar las actividades y describirlas con suficiente detalle. De esta forma, al menos, podr reducir la probabilidad
de encontrarse con sorpresas desagradables.

Fase Actividad

Anlisis * Recopilacin de datos anlisis y el flujo de datos
y de decisiones
*Preparacin de la propuesta
Diseo
*Diseo de la captura de datos
*Diseo de entradas
*Diseo de salidas
*Organizacin de datos
Implementacin
*Implementacin
Evaluacin

Fig. 3.5

Actividad Actividad detallada Semanas requeridas
Recopilacin de datos Realizar entrevistas 3
Aplicar cuestionarios 4
Leer informes de la compaa 4
Introducir prototipos 5
Observar las reacciones hacia los prototipos 3

Anlisis del flujo de datos Anlisis del flujo de datos 8
y de decisiones

Preparacin de la propuesta
Realizar anlisis de costos y beneficios 3
Preparar la propuesta 2
Presentar la propuesta 2

Fig. 3.6

USO DE GRFICAS DE GANTT PARA LA PROGRAMACIN DE PROYECTOS
Una grfica de Gantt es una forma fcil de programar tareas. En este tipo de grfica las barras representan cada tarea
o actividad. La longitud de cada barra representa la duracin relativa de dicha tarea.
La figura 3.7 es un ejemplo de una grfica de Gantt bidimensional en la cual el tiempo se indica en la dimensin
horizontal y la descripcin de las actividades se encuentra en la dimensin vertical. En este ejemplo la grfica muestra
la fase de anlisis o de recopilacin de informacin del proyecto. Se observa que tomar tres semanas llevar a cabo las
entrevistas, aplicar los cuestionarios tomar cuatro semanas, y as sucesivamente. Estas actividades se sobreponen
parte del tiempo. El smbolo A en la grfica significa que la semana actual es la 9. Las barras sombreadas representan
proyectos o parte de stos que se han terminado, lo cual nos indica que el analista de sistemas est atrasado en la
introduccin de prototipos, pero adelantado en el anlisis de flujo de datos. Deben tomarse medidas inmediatas en la
introduccin de prototipos para evitar que otras actividades o incluso el proyecto mismo se atrasen.
La principal ventaja de la grfica de Gantt es su sencillez. El analista de sistemas se dar cuenta de que esta tcnica no
slo es fcil de utilizar, sino que tambin es adecuada para establecer una comunicacin satisfactoria con los usuarios
finales. Otra ventaja de utilizar la grfica de Gantt es que las barras representan actividades o tareas a escala; es decir,
el tamao de las barras indica el tiempo relativo que tomar completar cada tarea.

Fig. 3.7

USO DE DIAGRAMAS PERT
PERT es un acrnimo de Program Evaluation and Review Techniques (Tcnicas de Evaluacin y Revisin de Programas).
Un programa (sinnimo de proyecto) se representa mediante una red de nodos y flechas que se evala para
determinar las actividades crticas, mejorar la programacin de fechas si es necesario y revisar el progreso una vez que
se aborda el proyecto.
PERT fue desarrollado a fines de la dcada de 1950 para utilizarse en el proyecto del submarino nuclear Polaris de la
Marina de Estados Unidos. Segn se dice, ahorr dos aos
de desarrollo a la Marina de Estados Unidos.
PERT es muy til cuando las actividades se pueden hacer en paralelo en lugar de en secuencia.
El analista de sistemas se puede beneficiar con PERT al aplicarlo a los proyectos de sistemas en una escala ms
pequea, especialmente cuando algunos miembros de un equipo
pueden trabajar en ciertas actividades al mismo tiempo que otros miembros del mismo equipo trabajan en otras
tareas.
En la figura 3.8 se comparan una grfica de Gantt sencilla y un diagrama PERT. Las actividades que se expresan como
barras en la grfica de Gantt, se representan como flechas en el diagrama PERT. La longitud de las flechas no tiene
relacin con la duracin de las actividades.
Los crculos en el diagrama PERT se denominan eventos y se pueden identificar mediante nmeros, letras o con
cualquier otra forma de designacin. El propsito de los nodos circulares es: [1) reconocer cuando una actividad est
terminada y [2) indicar las actividades que deben terminarse antes de emprender nuevas actividades [precedencia).
En realidad la actividad C no puede empezar sino hasta que la actividad A est terminada.
La precedencia no se indica en la grfica de Gantt, de tal modo que no es posible saber si la actividad C est
programada para iniciar el da 4 a propsito o por coincidencia.
Un proyecto tiene un inicio, un punto medio y un fin; el inicio es el evento 10 y el fin es el evento 50. Para encontrar la
duracin del proyecto se identifica cada ruta desde el inicio hasta el fin y se calcula la duracin de cada ruta. En este
ejemplo la ruta 10-20-40-50 tiene una duracin de 15 das, mientras que la de la ruta 10-30-40-50 es de 11 das. Aun
cuando una persona podra trabajar en la ruta 10-20-40-50 y otra en la ruta 10-30-40-50, el proyecto no es una carrera.
El proyecto requiere que ambos conjuntos de actividades (o rutas) se terminen; en consecuencia, toma 15 das
terminar el proyecto.
La ruta ms larga se denomina ruta crtica. Aunque la ruta crtica se determina calculando la ruta ms larga, sta se
define como la ruta que causar que el proyecto entero se atrase incluso si se retrasa un solo da. Observe que si usted
se retrasa un da en la ruta 10-20-40-50, el proyecto entero se alargar, pero si se retrasa un da en la ruta 10-30-40-50,
ninguna parte del proyecto lo resentir. La libertad para retrasarse en algn punto de las rutas no crticas se conoce
como tiempo de holgura.
Ocasionalmente, los diagramas PERT necesitan pseudoactividades, referidas como actividades simuladas, para
preservar la lgica o clarificar el diagrama. La figura 3.9 muestra dos diagramas PERT con actividades simuladas. Los
proyectos 1 y 2 son un poco diferentes, y la forma en que estn trazadas las actividades simuladas hace evidente esta
diferencia. En el proyecto 1 la actividad C slo puede iniciar si las actividades A y B han terminado, debido a que todas
las flechas que entran en un nodo deben terminarse antes de abandonar el nodo.
Sin embargo, en el proyecto 2 la actividad C slo requiere que la actividad B sea terminada
y por lo tanto puede iniciar aunque todava se est realizando la actividad A.
Completar el proyecto 1 toma 14 das, mientras que para el proyecto 2 tan slo son necesarios 9 das. Por supuesto, en
el proyecto 1 es necesaria la actividad simulada, debido a que indica una relacin crucial de precedencia. Por otro lado,
en el proyecto 2 no se requiere la actividad simulada, y la actividad A se podra haber trazado del 10 al 40 y se podra
haber eliminado por completo el evento 20.





Fig.3.8







Fig.3.9







Lista de actividades que se usan
para dibujar un diagrama PERT

Actividad Predecesor Duracin
A Realizar entrevistas Ninguno 3
B Aplicar cuestionarios A 4
C Leer informes de la
compaia
Ninguno 4
D Analizar el flujo de datos B,C 8
E Introducir prototipos B,C 5
F Observar las reacciones
hacia el prototipo
F 3
G Realizar anlisis de costos
y beneficio
D 3
H Preparar la propuesta F, G 2
I Presentar la propuesta H 2
Por lo tanto, hay varias razones para utilizar el diagrama PERT en vez de la grfica de Gantt. El diagrama PERT permite:
1. Identificar fcilmente el orden de precedencia.
2. Identificar fcilmente la ruta crtica y por consiguiente las actividades crticas.
3. Determinar fcilmente el tiempo de holgura.

ESTRATEGIAS DE COMUNICACIN PARA ADMINISTRAR EQUIPOS
Los equipos tienen su propia personalidad, resultado de la combinacin de cada uno de los miembros individuales del
equipo con los dems miembros de una manera que crea una red
de interacciones totalmente nueva. Una forma de estructurar la manera en que concibe a los equipos es visualizarlos
siempre en una bsqueda constante de equilibrio entre la consecucin de las tareas en turno y el mantenimiento de
las relaciones entre los miembros del equipo.
De hecho, por lo regular los equipos tendrn dos lderes, no slo uno. Generalmente una persona se encargar de
guiar a los miembros a la consecucin de tareas, y otra se ocupar de las relaciones sociales entre los miembros del
grupo. Ambos son necesarios para el equipo. Algunos investigadores han denominado a estos individuos como lder de
tareas y lder socioemocional, respectivamente. Todos los equipos padecen las tensiones derivadas de la bsqueda de
un equilibrio entre la consecucin de las tareas y el mantenimiento de las relaciones entre los miembros del equipo.
Para que contine la eficiencia del equipo, es necesario solucionar continuamente las tensiones. Si se resta
importancia a las tensiones o se ignoran, stas conducirn a la ineficiencia y a la desintegracin eventual del equipo.
Gran parte de la liberacin de la tensin se puede lograr mediante un uso inteligente de la retroalimentacin por todos
los miembros del equipo. Sin embargo, todos los miembros deben estar de acuerdo en que la forma en que
interactan (es decir, los procesos) es suficientemente importante para ameritar algn tiempo. Para garantizar el
acuerdo sobre la interaccin apropiada entre los miembros es necesaria la creacin de normas explcitas e implcitas
(expectativas, valores y formas de comportamiento colectivos) que guen las relaciones entre los miembros. Las
normas son exclusivas de los equipos y no es necesario que se transfieran de un equipo a otro. Estas normas cambian
constantemente y es mejor considerarlas como un proceso de interaccin de los equipos y no como un producto.
Las normas pueden ser funcionales o disfuncionales. El hecho de que un comportamiento particular sea una norma
para un equipo no significa que le ayudar a conseguir sus metas. Por ejemplo, la expectativa de que los miembros
ms recientes de un equipo se encarguen de toda la programacin del proyecto podra ser una norma de equipo. Al
apegarse a esta norma, el equipo ejercera una fuerte presin sobre los miembros ms nuevos y no aprovechara la
experiencia de los dems miembros del equipo. sta es una norma que, de continuar, podra ocasionar que los
miembros del equipo desperdiciaran recursos valiosos.
Los miembros del equipo necesitan hacer explcitas las normas y evaluar peridicamente si dichas normas son
funcionales o disfuncionales para ayudar al equipo a conseguir sus metas.
La expectativa ms importante para su equipo debe ser que el cambio es la norma. Pregntese si las normas del
equipo estn fomentando u obstaculizando el progreso del equipo.
FIJACIN DE LAS METAS DE PRODUCTIVIDAD DEL PROYECTO
Cuando ha trabajado con los miembros de su equipo en diferentes tipos de proyectos, usted
o el lder de su equipo adquirirn habilidad para proyectar lo que puede conseguir el equipo
en un periodo especfico. Al utilizar las sugerencias descritas en la seccin sobre mtodos para calcular el tiempo
requerido y aplicndolas de manera conjunta con la experiencia el equipo podr fijar metas de productividad
benficas.
Los analistas de sistemas estn acostumbrados a las metas de productividad para empleados
que muestran salidas tangibles, tales como el nmero de pantalones vaqueros azules cosidos por hora, el nmero de
entradas capturadas por minuto, o el nmero de artculos escaneados por segundo. Sin embargo, conforme se
incrementa la productividad en la manufactura, est claro que la productividad del rea administrativa debe
incrementarse tambin. Con esta finalidad en mente se fijan las metas de productividad para el equipo de
anlisis de sistemas.
Es necesario que el equipo formule las metas y est de acuerdo con ellas, y que lo haga con base en la experiencia de
todos sus miembros, el desempeo anterior y la naturaleza del proyecto especfico. Las metas variarn un poco para
cada proyecto que se emprenda, porque en ocasiones el proyecto consistir en la instalacin de un sistema completo,
y en otros casos tal vez slo se realicen algunas modificaciones a una parte de un sistema existente.
MOTIVACIN A LOS MIEMBROS DEL EQUIPO DE UN PROYECTO
A pesar de que la motivacin es un tema sumamente complejo, en este punto es importante
considerarlo, aun cuando sea de manera breve. Recordemos que los individuos se agrupan en organizaciones para
satisfacer algunas de sus necesidades bsicas como el cobijo, vestido y sustento. No obstante, todos tenemos tambin
necesidades ms elevadas, como la pertenencia a un grupo, el control, la independencia y la creatividad. Todos los
individuos tenemos motivacin para satisfacer necesidades en diversos aspectos.
Los miembros de un equipo se pueden motivar, al menos en parte, involucrndolos en la fijacin de metas, como
vimos en la seccin anterior. El simple acto de fijar una meta desafiante pero alcanzable y de medir peridicamente el
desempeo contra la meta establecida parece eficaz para motivar a los individuos. Las metas sirven como imanes para
atraer a los individuos a la consecucin de stas.
Parte de la razn de que la fijacin de metas motive a los individuos consiste en que los miembros de un equipo saben
exactamente lo que se espera de ellos con antelacin a cualquier revisin del desempeo. El xito de la fijacin de
metas con el fin de motivar tambin se puede conseguir dando un poco de autonoma a cada miembro del equipo para
la consecucin de las metas. Aunque una meta se fija de antemano, tal vez no ocurra lo mismo con los medios para
alcanzarla. En este caso los miembros del equipo tienen libertad para recurrir a sus propios conocimientos y
experiencia para cumplir sus metas.
La fijacin de metas tambin puede motivar a los miembros del equipo pues les aclara tanto a ellos como a los dems
lo que se tiene que hacer para conseguir resultados. Asimismo,las metas motivan a los miembros del equipo porque
definen el grado de xito que se espera de ellos. Esta forma de utilizar las metas simplifica la atmsfera laboral, pero
tambin la estimula con la perspectiva de que lo esperado se puede conseguir
COMO EVITAR EL FRACASO DE UN PROYECTO
Por lo general, las primeras conversaciones que sostenga con los directivos y dems involucrados en la solicitud de un
proyecto, junto con los estudios de viabilidad que realice, son sus mejores defensas para rechazar proyectos que
tengan una alta probabilidad de fracaso.
La prctica y la experiencia mejorarn su capacidad para evaluar si un proyecto vale la pena y las razones que motivan
a los dems a solicitarlo. Si usted es miembro de un equipo interno de anlisis de sistemas, debe mantenerse al tanto
del clima poltico de la organizacin, as como de su situacin financiera y competitiva.
Tambin puede aprender de la experiencia adquirida por las personas involucradas en los fracasos de proyectos
anteriores. Al pedirle a programadores profesionales que expliquen las razones por las cuales han fallado algunos
proyectos, argumentan la fijacin de fechas irreales o imposibles de cumplir por parte de los directivos, la creencia de
que basta con incorporar ms gente a un proyecto para acelerarlo (a pesar de que la fecha original para la terminacin
del proyecto era irreal], y la actitud irreflexiva de los directivos al prohibir al equipo que recurra al conocimiento de
profesionales externos en busca de ayuda para solucionar problemas especficos.
Recuerde que no recae en usted toda la responsabilidad de tomar la decisin de dar inicio a un proyecto. A pesar de
que su equipo de anlisis de sistemas hace sugerencias, los directivos son quienes deciden si un proyecto propuesto es
digno de un estudio ms profundo (es decir, de una mayor inversin de recursos]. El proceso de toma de decisiones de
su equipo debe ser abierto y soportar el anlisis minucioso de quienes no pertenecen a l. Los miembros del equipo
deben estar conscientes de que su reputacin y permanencia en la organizacin dependen estrechamente de los
proyectos que acepten.