ADMINISTRACION DE PROYECTOS -PRIMERA PARTE

INDICE
ADMINISTRACION DE PROYECTOS -PRIMERA PARTE ....................................................................1
INICIACIÓN DEL PROYECTO ..........................................................................................................1
Problemas en la organización ...................................................................................................1
Definición del problema ...........................................................................................................2
Selección de proyectos .............................................................................................................4
DETERMINACIÓN DE LA VIABILIDAD ............................................................................................5
Determinar si es posible o no ...................................................................................................6
VIABILIDAD TÉCNICA ................................................................................................................6
VIABILIDAD ECONÓMICA ..........................................................................................................7
VIABILIDAD OPERACIONAL .......................................................................................................7
PREGUNTAS DE REPASO: ..............................................................................................................7
CASOS DE CONSULTA Y PROBLEMAS ........................................................................................8

INICIACIÓN DEL PROYECTO

Los proyectos de sistemas tienen muchos orígenes y diversas razones. Algunos de los proyectos
sugeridos sobrevivirán varias de las etapas de evaluación en las que usted (o usted y su equipo)
debe trabajar; otros no deben sobrevivir (ni sobrevivirán) tanto. Los empresarios sugieren
proyectos de sistemas por dos amplios tipos de razones:

1) porque experimentan problemas que se prestan por sí solos a las soluciones de sistemas

2) porque reconocen oportunidades para mejorar mediante la actualización o modificación de

los sistemas existentes, o la instalación de sistemas nuevos.

Ambas situaciones pueden surgir a medida que la organización se adapta y hace frente a los
cambios naturales y evolucionarios.

Problemas en la organización

A los gerentes no les gusta que su organización tenga problemas y mucho menos hablar sobre
ellos o compartirlos con alguien externo. Sin embargo, los buenos gerentes están conscientes de
que es imprescindible reconocer los síntomas de los problemas o, en una etapa posterior,
diagnosticar los problemas en sí y luego confrontarlos, si quieren que su empresa siga
funcionando con el mayor potencial posible. Los problemas salen a la superficie de muchas
formas. Una manera de conceptualizar qué son los problemas y cómo surgen es considerarlos
como situaciones en las que nunca se cumplieron los objetivos o dejaron de cumplirse en algún
punto. La retroalimentación práctica proporciona información sobre el hueco entre el
rendimiento actual y el esperado, y, de esta forma, ayuda a destacar los problemas. En algunos
casos, los problemas que requieren de los servicios de los analistas de sistemas se descubren
debido a que no se están cumpliendo las medidas de rendimiento. Los problemas (o síntomas
de ellos) con procesos que no son visibles en el proceso de salida y que podrían requerir la ayuda
de un analista de sistemas; incluyen errores excesivos y un trabajo que se desempeña con mucha
lentitud, en forma incompleta, incorrecta o que simplemente no se lleva a cabo. Otros síntomas
de los problemas se hacen evidentes cuando las personas no cumplen con los objetivos de
rendimiento de referencia. Los cambios en el comportamiento de los empleados, como niveles
altos e inusuales de ausentismo, una gran inconformidad en el trabajo o mucha rotación de
personal son factores que alertan a los gerentes sobre problemas potenciales. Cualquiera de
estos cambios, por sí solos o combinados, podría ser motivo suficiente para solicitar la ayuda de
un analista de sistemas. Aunque las dificultades como las que acabamos de describir ocurren en
la organización, la retroalimentación acerca de la forma en que la organización cumple con los
objetivos designados puede provenir del exterior, en forma de quejas o sugerencias de los
clientes, distribuidores o proveedores, además de la pérdida de ventas o una reducción
inesperada en las mismas. Esta retroalimentación proveniente del entorno externo es en
extremo importante y no debe ignorarse. Al reaccionar a las historias de los problemas en la
organización, el analista de sistemas desempeña los roles de consultor, experto de soporte y
agente de cambio. Como podría esperar, los roles para el analista de sistemas cambian
sutilmente cuando se inician los proyectos, ya que el enfoque está en las oportunidades de
mejorar en vez de estar en la necesidad de resolver los problemas.

Definición del problema

Sin importar que utilice el SDLC clásico o una metodología orientada a objetos, el analista
primero define los problemas y objetivos en el sistema. Éstos forman la base para determinar
qué debe lograr el sistema. Hay métodos para empezar con una definición del problema.

Por lo general, la definición de un problema contiene cierta clase de declaración del mismo,
sintetizada en uno o dos párrafos. A ésta le siguen una serie de cuestiones o piezas
independientes importantes del problema. Estas cuestiones van seguidas de una serie de
objetivos o metas que coincidan con cada uno de los puntos establecidos en las cuestiones. Las
cuestiones son la situación actual; los objetivos son la situación deseada. Los objetivos pueden
ser muy específicos o se pueden redactar mediante una declaración general. He aquí algunos
ejemplos de preguntas de negocios relacionadas con los objetivos de una empresa:

• ¿Cuáles son los propósitos de la empresa?

• ¿Es una empresa con o sin fines de lucro?
• ¿Planea la compañía crecer o expandirse?
• ¿Cuál es la postura de la empresa (cultura) en cuanto a la tecnología?
• ¿Cuál es el presupuesto que la empresa tiene asignado para la TI?
• ¿El personal de la empresa tiene la experiencia requerida?

Sobra decir que el analista de sistemas debe comprender la forma en que funciona la empresa.
La última parte de la definición del problema contiene los requerimientos, las cosas que se deben
lograr, junto con las posibles soluciones y las restricciones que limitan el desarrollo del sistema.
La sección de requerimientos puede incluir seguridad, capacidad de uso, requerimientos
gubernamentales, etcétera. A menudo las restricciones incluyen la palabra no para indicar una
limitación, y pueden contener restricciones en el presupuesto o límites de tiempo. La definición
del problema se produce después de terminar con las entrevistas, las observaciones y el análisis
de los documentos con los usuarios. El resultado de recopilar esta información es una enorme
cantidad de hechos y opiniones importantes que debe sintetizarse. El primer paso para producir
la definición del problema es encontrar varios puntos que se puedan incluir en una cuestión. Los
puntos importantes se pueden identificar en la entrevista de distintas formas:

1. Los usuarios pueden identificar una cuestión, asunto o tema que se repita varias veces; en
ocasiones pueden ser distintas personas en varias entrevistas.

2. Los usuarios pueden comunicar las mismas metáforas, como decir que la empresa es un viaje,
un juego de guerra, un organismo, una máquina, etcétera.

3. Los usuarios pueden hablar mucho sobre un tema.

4. Los usuarios le pueden decir abiertamente: “Éste es un problema importante”.

5. Los usuarios pueden comunicar la importancia mediante el lenguaje corporal o hablar

tajantemente sobre una cuestión.

6. El problema puede ser lo primero que mencione el usuario.

Una vez creadas las cuestiones hay que declarar los objetivos. A veces, el analista debe realizar
una entrevista de seguimiento para obtener información más precisa sobre los objetivos. Una
vez declarados éstos, hay que determinar la importancia relativa de las cuestiones o de los
objetivos. Si no hay suficientes fondos para desarrollar el sistema completo, primero es necesario
completar los objetivos más críticos. Los usuarios son quienes pueden identificar mejor los
objetivos más críticos (con la ayuda de los analistas), ya que son expertos de dominio en su área
de negocios y saben cómo trabajar mejor con las tecnologías en la organización. Una de las
técnicas es pedir a los usuarios que asignen una ponderación para cada cuestión u objetivo del
primer borrador de la definición del problema. Es un juicio subjetivo por parte del usuario, pero
si varios de ellos asignan ponderaciones y se obtiene un promedio de todas, el resultado podría
reflejar mejor la situación. Después de determinar las ponderaciones se modifica la secuencia
del orden de las cuestiones y objetivos de la definición del problema en orden de mayor a menor
importancia. Existe software como Expert Choice (www. expertchoice.com) y otros paquetes de
software de soporte de decisiones que pueden ayudar con los procesos de pesar y asignar
prioridades a los objetivos. Además de analizar los datos y entrevistar personas, trate de
presenciar el problema por su cuenta. Al analizar la misma situación, tal vez un empleado pueda
ver un problema en forma muy distinta a un analista de sistemas. Esto también ofrece a los
analistas la oportunidad de confirmar sus hallazgos. De esta forma utilizan varios métodos, con
lo cual fortalecen el caso para tomar la acción apropiada

Selección de proyectos

Los proyectos tienes orígenes distintos y se inician por muchas razones. No todos se deben
seleccionar para continuar su estudio. Como analista, usted debe tener razones muy claras para
recomendar un estudio de sistemas en un proyecto que parezca resolver un problema o que
pudiera dar lugar a una mejora. Tome en cuenta la motivación detrás de una propuesta para el
proyecto. Necesita estar seguro de que el proyecto en consideración no se proponga sólo por
mejorar su propia reputación o su poder ni el de la persona o grupo que lo propone, ya que hay
una buena probabilidad de que dicho proyecto sea mal concebido y que en un momento dado
no sea muy bien aceptado. Como y vimos, hay que examinar los proyectos que se tengan como
prospectos desde una perspectiva de sistemas, de tal forma que consideremos el impacto del
cambio propuesto en toda la organización. Recuerde que los diversos subsistemas de la
organización están interrelacionados y son interdependientes, por lo que un cambio en un
subsistema podría afectar a los demás. Incluso cuando los encargados de tomar las decisiones
que están directamente involucrados son los que en última instancia establecen los límites para
el proyecto de sistemas, no podemos contemplar o seleccionar un proyecto de sistemas aislados
del resto de la organización. Además de estas consideraciones generales tenemos cinco criterios
específicos para la selección de proyectos:

1. Contar con el respaldo de la administración.

2. Que sea el momento oportuno para comprometerse con el proyecto

3. La posibilidad de mejorar la obtención de los objetivos de la organización.

4. Que sea práctico en términos de recursos para el analista de sistemas y la organización.

5. Que el proyecto valga la pena en comparación con las demás formas en que la organización
podría invertir sus recursos.

Antes que nada, está el respaldo de la administración. No se puede lograr nada en absoluto sin
el patrocinio de las personas que en un momento dado tendrán que pagar la cuenta. Esto no
significa que usted no tenga influencia para dirigir el proyecto o que no se puedan incluir otras
personas aparte de la administración, pero sí que su respaldo es esencial. Otro criterio
importante para la selección de un proyecto es que suceda en el momento oportuno para usted
y la organización. Pregúntese a sí mismo y a los demás involucrados si la empresa es capaz en
esos momentos de comprometerse con el tiempo requerido para la instalación de nuevos
sistemas o para mejorar los sistemas existentes. Usted también debe ser capaz de comprometer
todo su tiempo (o la parte necesaria del mismo) durante este periodo. Un tercer criterio es la
posibilidad de mejorar el logro de los objetivos de la organización como

1) mejorar las ganancias de la empresa,

2) brindar soporte a la estrategia competitiva de la organización,

3) mejorar la cooperación con los distribuidores y socios,

4) mejorar el soporte a las operaciones internas de manera que los productos y servicios se
produzcan con eficiencia y efectividad,

5) mejorar el soporte a las decisiones internas de manera que éstas sean más efectivas,

6) mejorar el servicio al cliente y

7) aumentar la moral de los empleados.

El proyecto debe encaminar a la organización hacia sus objetivos primordiales y no desviarla de

ellos. El cuarto criterio es seleccionar un proyecto que sea práctico en términos de sus recursos
y capacidades, así como las de la empresa. Algunos proyectos no estarán dentro de su área de
experiencia, por lo cual debe ser capaz de reconocerlos. Por último, necesita llegar a un acuerdo
básico con la organización en cuanto a si vale la pena el proyecto de sistemas en comparación
con cualquier otro posible proyecto que se esté considerando. Hay muchas posibilidades para
realizar mejoras como

1) agilizar un proceso,

2) optimizar un proceso por medio de la eliminación de pasos innecesarios o duplicados,

3) combinar procesos,

4) reducir errores en la entrada por medio de cambios en los formularios y las pantallas de
visualización,

5) reducir el almacenamiento redundante,

6) reducir la salida redundante y

7) mejorar la integración de los sistemas y subsistemas.

Recuerde que cuando una empresa se compromete con un proyecto, está comprometiendo los
recursos que podrían ya no estar disponibles para otros. Es conveniente considerar que todos
los posibles proyectos compiten por los recursos de tiempo, dinero y personal de la empresa.

DETERMINACIÓN DE LA VIABILIDAD
Una vez que reducimos el número de proyectos de acuerdo con los criterios antes descritos,
todavía falta determinar si los proyectos seleccionados son viables. Nuestra definición de
viabilidad va mucho más allá del uso común del término, ya que existen tres formas principales
para evaluar la viabilidad de los proyectos de sistemas: en base a su operación, a su capacidad
técnica y a su economía. El estudio de viabilidad no es un estudio detallado de sistemas, sino
que se utiliza para recopilar datos más generales para los miembros de la administración, lo cual
a su vez les permite tomar una decisión en cuanto a si deben continuar o no con un estudio de
sistemas. Los datos para el estudio de viabilidad se pueden recuperar a través de entrevistas. El
tipo de entrevista requerida está relacionado de manera directa con el problema u oportunidad
que se sugiere. Por lo general, el analista de sistemas entrevista a las personas que piden ayuda
y a las que están relacionadas en forma directa con el proceso de toma de decisiones, que
generalmente son los administradores. Aunque es importante abordar el problema correcto, el
analista de sistemas no debe invertir mucho tiempo en realizar estudios de viabilidad, ya que se
solicitarán muchos proyectos y se podrán o deberán llevar a cabo sólo unos cuantos. El estudio
de viabilidad debe tardar el menor tiempo posible, procurando abarcar varias actividades en un
periodo de tiempo corto.

Determinar si es posible o no

Una vez que el analista determina objetivos razonables para un proyecto, necesita determinar si
es posible que la organización y sus miembros puedan ver el proyecto hasta su terminación. Por
lo general, el proceso de evaluación de la viabilidad es efectivo para descartar proyectos
inconsistentes con los objetivos de la empresa, que requieran una capacidad técnica imposible
o que no tengan ningún mérito económico. Aunque es meticuloso, el estudio de la viabilidad es
algo que vale la pena ya que ahorra tiempo y dinero a las empresas y a los analistas de sistemas.
Para que el analista pueda recomendar que se continúe con el desarrollo de un proyecto, éste
debe mostrar que es viable en las tres siguientes formas: técnica, económica y operacional.

VIABILIDAD TÉCNICA
El analista debe averiguar si es posible desarrollar el nuevo sistema teniendo en cuenta los
recursos técnicos actuales. De no ser así, ¿se puede actualizar o complementar el sistema de tal
forma que pueda cumplir con lo que se requiere? Si no es posible complementar o actualizar los
sistemas existentes, la siguiente pregunta es si existe o no la tecnología que cumpla con las
especificaciones. Al mismo tiempo, el analista puede preguntar si la organización cuenta con el
personal que tenga la habilidad técnica suficiente para lograr los objetivos. De no ser así, la
pregunta es si pueden o no contratar programadores, probadores, expertos o demás personal
adicional que pueda tener habilidades de programación distintas a las del personal existente, o
si tal vez pueden subcontratar un tercero para que se haga cargo del proyecto. Otra de las
preguntas es si hay o no paquetes de software disponibles que puedan lograr sus objetivos, o si
hay que personalizar el software para la organización.

VIABILIDAD ECONÓMICA
La viabilidad económica es la segunda parte de la determinación de recursos. Los recursos
básicos a considerar son el tiempo de usted como analista y el tiempo de su equipo de análisis
de sistemas, el costo de realizar un estudio de sistemas completo (incluyendo el tiempo de los
empleados con los que usted va a trabajar), el costo del tiempo del empleado de la empresa, el
costo estimado del hardware y el costo estimado del software o del desarrollo de software. La
empresa afectada debe ser capaz de ver el valor de la inversión que está considerando antes de
comprometerse con un estudio de sistemas completo. Si los costos a corto plazo no se ven
eclipsados por las ganancias a largo plazo o no producen una reducción inmediata en los costos
de operación, entonces el sistema no es económicamente viable y el proyecto no debe continuar.

VIABILIDAD OPERACIONAL
Suponga por un instante que tanto los recursos técnicos como económicos se consideran
adecuados. El analista de sistemas debe aún considerar la viabilidad operacional del proyecto
solicitado. La viabilidad operacional depende de los recursos humanos disponibles para el
proyecto e implica la acción de pronosticar si el sistema funcionará y se utilizará una vez
instalado. Si los usuarios están prácticamente casados con el sistema actual, no ven problemas
con él y por lo general no están involucrados en el proceso de solicitar un nuevo sistema, habrá
mucha resistencia a la implementación del nuevo. Las probabilidades de que se vuelva funcional
en algún momento dado serán bajas. Por otro lado, si los mismos usuarios han expresado la
necesidad de un sistema que sea funcional por más tiempo, de una forma más eficiente y
accesible, hay más probabilidades de que el sistema solicitado se llegue a utilizar en un momento
dado. Gran parte del arte de determinar la viabilidad operacional recae en las interfaces de
usuario elegidas

PREGUNTAS DE REPASO:

1. ¿Cuáles son los cinco fundamentos principales de un proyecto?

2. Mencione tres formas de averiguar sobre los problemas o las oportunidades potencialmente
asociados con una solución de sistemas.

3. Enliste los cinco criterios para la selección de proyectos de sistemas.

4. Defina viabilidad técnica.

5. Defina viabilidad económica.

6. Defina viabilidad operacional

CASOS DE CONSULTA Y PROBLEMAS

1. Williwonk’s Chocolates de St. Louis fabrica varios tipos de dulces y novedades de

chocolate. La empresa tiene seis tiendas en la ciudad: cinco en los principales
aeropuertos metropolitanos y una pequeña sucursal de pedidos por correo. Williwonk’s
tiene un pequeño sistema de información computarizado que rastrea el inventario en su
planta, ayuda a programar la producción y algunas otras cosas más, pero este sistema
no está enlazado directamente con ninguna de sus tiendas de menudeo. El sistema de
pedidos por correo se administra en forma manual. Hace poco, varias tiendas de
Williwonk’s experimentaron una erupción de quejas de los clientes de pedidos por
correo, debido a que los dulces llegaban echados a perder, que no llegaban cuando se
les prometía o que nunca llegaban; la empresa también recibió varias cartas en las que
se quejaban de que los dulces en varios aeropuertos sabían rancios. Williwonk’s ha
estado vendiendo una nueva forma dietética de chocolate bajo en calorías, formulada
con un edulcorante artificial. Las ventas han sido activas, pero han surgido problemas
por enviar el tipo incorrecto de chocolate a la dirección en la que vive una persona
diabética. Hubo varias quejas, por lo que Williwonk’s envió varias cajas gratis de
chocolate como desagravio. A la gerencia le gustaría vender productos a través de Web,
pero cuentan con sólo algunas páginas Web con información sobre la compañía y un
formulario de pedidos que se puede imprimir. No existen los pedidos a través de Web.
A uno de los ejecutivos principales le gustaría vender chocolates personalizados con el
nombre de una persona en cada pieza. Aunque el área de producción aseguró a la
gerencia que esto se podría hacer fácilmente, no hay un método para pedir tales
chocolates personalizados. Otro de los ejecutivos principales mencionó que Williwonk’s
se asoció con varios fabricantes de chocolate europeos y que importará chocolate de
varios países. En la actualidad hay que hacer esto a través del teléfono, por correo
electrónico o por correo convencional. El ejecutivo desea un sitio Web interno que
permita a los empleados realizar pedidos directamente a las empresas asociadas. Todo
esto ha provocado que varios gerentes soliciten un análisis de tendencias. Cuando hay
inventario en exceso algunos chocolates se arrancian, mientras que otras veces hay
escasez de ciertos tipos de chocolate. Las tendencias de variación por temporadas y días
festivos podrían ayudar a Williwonk’s a mantener un inventario adecuado. El gerente de
control de inventario insiste en que es necesario implementar todos los cambios antes
de la siguiente temporada festiva. “Hay que tener una fecha absoluta definida para que
todo esté terminado”, recalcó Candy, una de los gerentes de nivel superior. “Debemos
asegurarnos de que todo esté trabajando perfectamente antes de que el sitio se haga
público”, continuó. “¡No quiero clientes que reciban los chocolates incorrectos!”.
Además, el gerente de procesamiento de pedidos mencionó que el sistema debe ser
seguro. Usted llevaba trabajando dos semanas con Williwonk’s en varias modificaciones
para su sistema de información de inventario cuando escuchó a dos gerentes discutir
sobre estas cuestiones.
Haga una lista de las posibles oportunidades o problemas que se podrían convertir en
proyectos de sistemas.

2. ¿De dónde proviene la mayor parte de la retroalimentación sobre los problemas con
los productos de Williwonk’s en el problema 1? ¿Qué tan confiables son las fuentes?
Explique en un párrafo.
3. Después de conocerlos mejor, usted se acerca a los ejecutivos de la administración de
Williwonk’s con sus ideas sobre las posibles mejoras de sistemas que podrían hacerse
cargo de algunos de los problemas o las oportunidades que se mencionan en el
problema 1.
a. Escriba en dos párrafos sus sugerencias para los proyectos de sistemas. Haga
todas las suposiciones realistas que sea necesario.
b. ¿Hay problemas u oportunidades descritas en el problema 1 que no sean
adecuadas? Explique su respuesta.