33483080 Administracion y Gestion de Proyectos Informaticos

5/28/2018 33483080 Administracion y Gestion de Proyectos Informaticos

1/200

Pg. 1 de 200

MANUALTCNICO

PMI-

IT

wwww.itcpcerbesa.com

Cristian BaileyConsultor IT

MANUAL TCNICO

METODOLOGA PARA LA ADMINISTRACIN YGESTIN DE

PROYECTOS INFORMTICOS.


2/200

Pg. 2 de 200

MANUALTCNICO

PMI-

IT



INTRODUCCIN:Generalmente las personas perciben a la informtica como una ciencia capaz de hacer castillos sobre el aire, y quetodas sus ideas se podrn representar en un desarrollo de Software determinado, pero al darse cuenta que losideales concebidos por ellos tienen un costo e involucran una serie de acciones resultan cambiando de opinin, espor ello que los proyectos en el rea de informtica son mas complejos, ya que el entregable es intangible,

causando desilusiones si las partes no entendieron exactamente que es lo que necesita cada una de ellas.

En la correcta definicin de las necesidades del cliente, as como la respectiva documentacin de estas necesidadesy los respectivos entregables que recibir el antes mencionado es donde radica el xito o fracaso de un proyecto deinformtica. Al tener bien definidas las dimensiones de las necesidades y entregables del cliente, los costes delproyectos sern mas certeros (siempre y cuando no surjan cambios en el transcurso del proceso) y los tiempos deentrega sern exactos.

A lo largo del manual tcnico se describirn tres grandes reas que componen la administracin de proyectos en elrea informtica, tales como:

1. Dimensin 1: Gestin de Proyectos.2. Dimensin 2: Aspectos tcnicos.3. Dimensin 3: Alineamiento con el Negocio.

Adems se conocern reas de la administracin y gestin de proyectos que permitirn tener bases y conocimientosgenerales de las tcnicas recomendadas por PMI en el PM BOOK para la correcta gestin de proyectos. Enresumen el presente documento esta compuesto en 5 captulos para su comprensin.

Cada una de las dimensiones antes mencionadas son parte integrales y entre lazadas entre si, ya que no se puedenobviar ninguna de ellas porque pueden provocar un fracaso en el desarrollo correcto del proyecto.

Este documento es complemento a publicaciones previas que he realizado por lo cual se citan los mismo por larelacin existente entre si. Dichos documentos se encuentran publicados bajos los nombres de:

Metodologa para seleccin sistemas empresariales y su implementacin.aspectos para auditoras de sistemas de informacin y tecnologas informticas e implementacin deestndares de seguridad informtica.

REFLEXIN:"Lainnovacinesloquedistingueallderdesusseguidores"


3/200

Pg. 3 de 200

MANUALTCNICO

PMI-

IT



CAPITULO 1LA ADMINISTRACIN DE PROYECTOS.

"Unbuenldernoesaquelquehacetemblarasussubordinados,unbuenldersehacerespetarporsuscolaboradores"


4/200

Pg. 4 de 200

MANUALTCNICO

PMI-

IT



MARCO DE REFERENCIA:

COMPRENDER EL PROCESO DE DIRIGIR PROYECTOS.Desde tiempos prehistricos los seres humanos han concebido y realizado proyectos, si comprendemos por tales a

emprendimientos temporarios cuyo objetivo est dirigido a cubrir diferentes necesidades humanas. Los proyectos,forman parte de nuestras vidas y en general los llevamos a cabo descuidadamente, no nos esforzamosconscientemente por dominarlos o dirigirlos.

El Management de Proyectos es de desarrollo reciente, como esfuerzo consciente por coordinar lo mseficientemente posible un presupuesto, un plan y los recursos en juego, para entregar el proyecto en tiempo ycalidad requerida.

QU ES UN PROYECTO?Es la bsqueda de una solucin inteligente a un problema tendiente a resolver, fundamentalmente, necesidadeshumanas. Es la combinacin de todos los recursos necesarios, reunidos en una organizacin temporal, para latransformacin de una idea en una realidad.

Previamente a la realizacin de cualquier proyecto es preciso estudiar seriamente la viabilidad, la utilidad econmicay social. Solo as es posible asignar los escasos recursos econmicos al mejor proyecto y a la mejor opcin.

Las caractersticas comunes de cualquier tipo de proyectos son las siguientes:

Estnorientadashaciaunobjetivo:consecucin de determinados resultados. Los objetivos son losque impulsan los proyectos, ya que la planificacin y el desarrollo se ponen en marcha para alcanzarlos.

Implicanacometercoordinadamenteunconjuntodeactividades interrelacionadas:unproyecto es un sistema, por lo que es bueno que el manager de proyecto utilice conceptos de la Teora deSistemas y alguna metodologa de anlisis de sistemas.

Duracinlimitada: los proyectos se realizan en un periodo finito, tienen un principio y un fin, que se

produce al alcanzar los objetivos bsicos. Aunque es preciso reconocer que los proyectos tienen fecha definalizacin bien definida, se debe tener en claro de que las responsabilidades del equipo de proyecto seextienden en muchos casos ms all de la entrega del producto.

Todas son, hasta cierto punto, nicas y no recurrentes: esta singularidad variaconsiderablemente de un proyecto a otro. Por lo tanto la experiencia pasada brinda poca orientacin precisaacerca de lo que se puede esperar, esto agrega riesgo e incertidumbre a los proyectos.

REFLEXIN:"Nopreguntesqupuedehacer

portielequipo.Preguntaqupuedeshacertporl"


5/200

Pg. 5 de 200

MANUALTCNICO

PMI-

IT



QU ES EL MANAGEMENT DE PROYECTO?Hay una triple limitacin que constituye el punto focal de la atencin y la energa del proyecto, el Management deproyecto est dirigido a llevar a cabo un proyecto lo ms eficazmente posible, teniendo en cuenta las limitacionesdetiempo,dinero(yrecursosengeneral)yespecificaciones.

Para hacerles frente a la triple limitacin han surgido diferentes herramientas:

TIEMPO: Se establecen plazos y se trabaja con horarios y agendas. Se cuenta para ello conHerramientas de Planificacin.

DINERO: Se maneja a travs de Presupuestos: estimaciones de costo, control y seguimiento.Existen varias herramientas para manejar los recursos materiales y humanos.

ESPECIFICACIONES: Describen como debe ser el producto del proyecto y que debe hacer. Sonnotoriamente difciles de establecer y controlar. Esta es la limitacin ms difcil demanejar.

EL CICLO DE VIDA DEL PROYECTO.Hay diversas maneras de considerar el ciclo vital del proyecto, una de las ms comunes estimas que se divide en 4grandes fases:Concepcindelproyecto,Planificacin,ImplementacinyFinalizacin.

Tiempo

Tiempo

Independientemente de cmo se considere el ciclo de vida el punto ms importante es que a lo largo de su vida todoproyecto es dinmico, es un emprendimiento en continua evolucin.

Nivelde

Recursosen($)

NiveldeRe

cursosen($)

Proyecto deinvestigacin de mercado

Proyecto deinvestigacin cientfica

REFLEXIN:"Demostrartuliderazgosignificaquecuandosurgenlosproblemaslos

enfrentasdeunamaneramadura,racionalysincera,pormuymolestoquete


6/200

Pg. 6 de 200

MANUALTCNICO

PMI-

IT



DINMICA DEL CICLO DE VIDA DEL PROYECTO.Se divide fundamentalmente en seis funciones, que se cumplen durante el curso del proyecto:

A).- Seleccin del Proyecto:

Los proyectos surgen de necesidades que debe ser satisfechas y debido a la existencia de recursos escasos sedebe decidir y seleccionar en base a las necesidades, el coste que suponen, los recursos y la importancia relativade satisfacer unas necesidades e ignorar otras. Tiene que ver con las prioridades y el Costo de Oportunidad.

Para tomar una decisin sobre un proyecto es necesario que este sea sometido al anlisis interdisciplinario. Unadecisin siempre debe estar basada en el anlisis de un sinnmero de antecedentes, con la aplicacin de unametodologa lgica que abarque la consideracin de todos los factores que participan y afectan al proyecto.

A medida que avanza el estudio, las opciones son mltiples en tamao, costos, tecnologas, organizacin, etc.Existen distintos criterios de evaluacin que se utilizarn para la seleccin y que tiene que ver con los valores delCEO, con el contexto y los anlisis: tcnico, econmico financiero, socioeconmico, ambiental, etc... Estos son loscriterios que tendr en cuenta el CEO para la aprobacin o no del proyecto y de la mejor opcin.

Se debern tener en cuenta adems los factores crticos de xito, que son aquellos aspectos que necesariamentedeben funcionar correctamente para que el proyecto, el proceso, la empresa sean exitosos.

Necesidades

Seleccin del Pro ecto

Planificacin del Proyecto

Implementacin del proyecto

Control del Proyecto

Terminacin

Evaluacin Evaluacin Evaluacin

REFLEXIN:"El mayor de los peligros para lamayora de nosotros, no es quenuestroobjetivoseademasiadoaltoy no lo alcancemos, sino que seademasiadobajoylologremos"


7/200

Pg. 7 de 200

MANUALTCNICO

PMI-

IT



Al momento de evaluar, previamente a la seleccin se deber demostrar que: Se presenta una oportunidad para mejorar los resultados econmicos, sociales y/o el posicionamiento de

la entidad. Existe una demanda insatisfecha. La opcin elegida es la mas conveniente tcnica, social y econmicamente. Se cuenta con recursos humanos y tcnicos para ejecutar y operar el proyecto. El proveedor es confiable. Los riesgos estn dentro de los parmetros aceptables. La solucin es econmicamente conveniente y su financiamiento posible. Que cumple con los criterios de evaluacin del o de los CEO.

Mtodos de evaluacin econmica de proyectos:A continuacin se presenta algunos de los mtodos utilizados para evaluar econmicamente a un proyecto; solo selos citan, pero el desarrollo metodolgico puede ser revisado en cualquier bibliografa de finanzas:

1. VAN (valor Actual Neto), surge de descontar a una tasa, o costo de oportunidad del capital, los flujosesperados durante el desarrollo del proyecto y hasta una cantidad de aos a definir o de funcionamiento enrgimen de la solucin implantada.

2. PERIODO DE RECUPERACIN, mide en que tiempo el proyecto devuelve su inversin inicial. Noconsidera los flujos totales sino los necesarios hasta la recuperacin.

3. TASA INTERNA DE RETORNO, es una medida de rentabilidad que surge de dividir el rendimiento sobrela inversin. Es la tas que hace al VAN igual a cero

4. RENDIMIENTO CONTABLE MEDIO, esta tasa surge de dividir el beneficio esperado de un proyectodespus de amortizacin e impuestos, por el valor medio de la inversin y se lo compara con el rendimientocontable de la entidad.

5. COSTO ACTUAL NETO, surge de descontar a una tasa o costo de oportunidad del capital los flujos decostos y gastos esperados. Se utiliza cuando no existen ingresos.

B).- Planificacin:Un plan es un mapa de ruta que nos indica como ir de un punto a otro, se parte de un plan informal o idea general;as tambin los estudios de factibilidad, el estudio de casos y los anlisis competitivos son preplanes. Su objetivo eslograr que los responsables de la ejecucin, ajusten el proyecto a sus objetivos, requerimientos y posibilidades.

Una vez que se decide afrontar un proyecto comienza la Planificacin Formal, se identifican los hitos, se fijan lastareas y su interdependencia, se debe lograr tambin el compromiso de sectores que participaran en su ejecucin-administracin y se identifican los responsables. Luego se debe planificar, revisar y ajustar a nivel de detalle laingeniera del proyecto, los recursos humanos, la tecnologa, adquisiciones, construcciones y financiamiento.Existen muchas herramientas: Estructuras de iniciacin de Proyectos, Diagramas de Gantt, de Red, de asignacinde recursos, de responsabilidad, etc.

A medida que el proyecto avanza, el plan puede sufrir continuas modificaciones, que reflejaran las circunstanciasimprevistas que se presente y las respuestas que se les de,por eso se dicen quelos pl anes son suposiciones.

C).- Implementacin:Desarrollar el proyecto una vez diseado el plan para producir algo que satisfaga las necesidades de los usuarios.Depende de la naturaleza especfica del proyecto.

En esta etapa se obtienen los insumos: recursos humanos, tecnologa, equipamientos, proveedores, etc para lapuesta en marcha del proyecto, por ejemplo:

Aplicativos integrados.Administradores de bases de datos.Redes, tipos, velocidad de transferencia.Tipos de monitores, equipos de multimedia.


8/200

Pg. 8 de 200

MANUALTCNICO

PMI-

IT



Plan de contingencias. Dispositivos de resguardo de informacin.

Se debe efectuar la preparacin y ajustes de los recursos humanos y fsicos en forma previa y durante laimplementacin.

D).- Control:A medida que se implementa el proyecto, sus administradores controlan continuamente el progreso, examinan loque se hizo hasta ese momento, recolectan y analizan de datos, estudian el plan y determinan si hay discrepanciasimportantes entre ambas cosas. En la Administracin de proyectos, esas discrepancias se llaman variaciones,desde un principio se tiene certeza absoluta de que estas estarn presentes debido al riesgo mencionadoanteriormente. Las variaciones siempre existirn, los niveles estimados como aceptables son determinados al iniciarel proyecto, de acuerdo al coste que implique respecto al total y al tipo de proyecto.

En esta etapa se efecta el seguimiento y los ajustes necesarios hasta la estabilizacin de las operaciones.

EL CONTROL DEL PROYECTO SE DIVIDE EN DOS REAS: Administracin del avance segn lo planeado. Gestin de los recursos y actividades que conlleva un proyecto.

ADMINISTRACIN DE PROYECTOS:Se define como el monitoreo de la ejecucin del mismo segn lo planeado, generalmente se usa el Gantt y Pert paraeste trabajo.

GESTIN DE PROYECTOS:Se define como la aplicacin de conocimientos, herramientas, y tcnicas a las actividades que conforman elproyecto, esto se refiere a la parte de documentar los procesos y generar alertas tempranas en base a la evolucinde los procesos.

E).- Evaluacin:Evaluaciones tcnicas y las revisiones crticas del diseo, las apreciaciones del personal, la Administracin por

Objetivos, las auditorias, etc. Tiene una importante labor de retroalimentacin peridica (durante y al finalizar elproyecto) del panorama generalizado, realizadas por un individuo o grupo que no trabaja directamente en elproyecto (para mantener la objetividad).

En esta etapa se evalan los resultados logrados, versus los esperados, se evalan tambin los desempeos y seimpulsan las mejoras continuas. La evaluacin es un examen objetivo y peridico para determinar el estado de unproyecto en relacin con sus objetivos especficos. En toda evaluacin se deberan cumplir los siguientes tems:

Se deben comparar objetivos y resultados esperados por los interesados en el proyecto. Se aplican mecanismos de medicin y evaluacin de resultados y desempeos. Se recomiendan acciones para reorientar o mejorar el proyecto. Se publicitan los resultados.

REFLEXIN:"No hay nadie menos afortunadoqueelhombreaquienlaadversidadolvida, pues no tiene oportunidaddeponerseaprueba"


9/200

Pg. 9 de 200

MANUALTCNICO

PMI-

IT



Evaluacin Intermedia:

NO SI

NO SI NO SI

NO SI NO SI

La evaluacin del informe final incluye los siguientes puntos: Costo del proyecto y de la operacin Cumplimiento del presupuesto y de los tiempos. Cumplimiento de especificaciones. Calidad de ejecucin y de la operacin. Capacidad de manejo de los recursos humanos y de conflictos. Transparencia. Resultados logrados vs. Proyectados. Resultados para sectores interesados. Recupero del proyecto.

F).- Terminacin:Puede ser abrupto o prematuro o terminen naturalmente. A pesar de que los proyectos terminen, lasresponsabilidades del manager continan a travs de diversas tareas finales, la reasignacin de tareas a losmiembros del equipo del proyecto, determinar si el proyecto satisface los requerimientos de los usuarios y laelaboracin de informes finales, recopilacin de documentacin, etc. Es necesario que estas tareas se lleven a cabopara evitar los problemas posproyecto o minimizarlos.

Aparece tambin la cuestin del MANTENIMIENTO, que incluye tareas como, eliminacin de fallas, ampliacin,integracin con otros sistemas, verificacin peridica de funcionamiento, etc. El mantenimiento de los sistemas esmuy importante, a pesar de esto no esta incluido en el ciclo vital del proyecto, puesto que los proyectos tienen unprincipio y un fin claramente definidos, el mantenimiento en cambio es permanente y de duracin indefinida.

Para realizar el mantenimiento o sustitucin se debe:Efectuar en todo momento un anlisis FODA.Cuestionar a todos los procesos y proyectos de la organizacinImpulsar en toda la organizacin la bsqueda de mejores soluciones que hagan obsoletas aun losproyectos histricos ms exitosos.

Estas seis funciones o etapas presentes en la vida del proyecto se observan a lo largo del ciclo de vida del mismo.

Es as que en la fase de Concepcin del proyecto se realiza la seleccin de proyecto, en la fase de planificacin se

Estamos alcanzando nuestros objetivos

Los Objetivos bsicos an son vlidos? Los Objetivos bsicos an son vlidos?

Terminar el Proyecto

Cambiar los objetivos y continuar con elproyecto

Adaptar el proyecto para alcanzar los objetivos

Queremos cambiar nuestros objetivos Queremos cambiar nuestros objetivos

Continuar con el proyecto

Cambiar los objetivos y continuar con el proyecto

Terminar el Proyecto


10/200

Pg. 10 de 200

MANUALTCNICO

PMI-

IT



presenta coincidentemente la funcin de planificacin del proyecto, mientras que en la fase de implementacin seencuentra en forma conjunta la fase de implementacin del proyecto y de control del mismo. En la fase deFinalizacin es posible observar la fase de Evaluacin y la Terminacin del proyecto.

EL MANAGEMENT DE PROYECTO DE TECNOLOGA INFORMTICA Y

SISTEMAS DE INFORMACINTradicionalmente fue utilizado en la industria de la construccin, la arquitectura y la ingeniera, en las ltimasdcadas, se comenz a trabajar crecientemente con intangibles: informacin y su manipulacin, el sector servicios.El rea de Management de proyecto que ms rpidamente crece es la del campo de la informacin: finanzas,marketing, salud y sistemas de informacin, entre otras; todas ellas se desenvuelven en un ambiente amorfo, fluidoy complejo.

LECCIONES CLAVES:El buen Management de proyecto puede aprenderse, para ello es necesario aprender dos lecciones fundamentales:

1 Leccin : Identificar y evitar las trampas.En todo proyecto algo andar mal, es una certeza, por lo que si se desea ceirse al plan original se enfrentarngrandes problemas. Buena parte de la tarea de los managers de proyecto consiste en minimizar las consecuenciasnegativas de esos problemas inesperados.

Las tres fuentes principales de fracaso de los proyectos son:

FACTORES ORGANIZACIONALES:1. Los problemas organizacionales son la norma en todo tipo de organizacin, la naturaleza misma del

Management de proyecto hace que surjan.

2. Una caracterstica comn es el divorcio entre responsabilidad y autoridad, al manager de proyecto no seles da control directo sobre todo el proceso, tiene poca autoridad directa para imponer su voluntad sobrelos individuos que trabajan en el proyecto.

3. Si el proyecto tiene xito, se deber a la habilidad del manager para influir sobre los principales agentes ycoordinar su trabajo, y tambin de la disposicin de esos agentes para cooperar con ella.

Mala identificacin de las necesidades del cliente y especificacin incorrecta de losrequerimientos:1. Un proyecto que produce algo que no se usa, porque no responde a sus necesidades o se usa poqusimo

porque genera en las resistencias, es un fracaso aunque se haya desarrollado en el plazo estipulado ydentro del presupuesto.

2. Esto se puede deber a que el producto refleja la visin de los altos puestos respecto de las necesidadesdel usuario, o refleja la opinin del diseador porque los clientes no saben bien lo que necesitan.

3. Muchas veces los problemas surgen despus de finalizado o a mitad del desarrollo, y ello ocasionaaumento de costos y plazos. Para evitarlos, los managers cuentan con tcnicas simples para definir ycontrolar con eficacia las necesidades y los requerimientos.

Planificacin y Control Deficientes:1. Una buena planificacin es una condicin necesaria, pero no suficiente para el xito del proyecto, los

controles nos permiten determinar si el plan est siendo realizado correctamente y en caso de sernecesario introducir ajustes necesarios para mantener el curso del proyecto.

2. Son actividades concretas y prcticas, se aplican a la distribucin del tiempo, de los recursos materiales yhumanos, son susceptibles de medicin y existen herramientas para trabajar en ambas reas.


11/200

Pg. 11 de 200

MANUALTCNICO

PMI-

IT



A pesar de esto, es comn que se los realice incorrectamente, sin embargo pueden transmitirse buenas prcticasde planificacin y control e incluso pueden automatizarse.El nico riesgo que persiste es encontrar el equilibrio de planificacin y control que no ahogue la

creatividad y la fluidez en el proyecto.

2 Leccin : Cmo crear las acciones correctasLa direccin de proyectos tiene que ver con el liderazgo y todo lo que implica, al igual que los conceptos deemprendimiento, o sea la capacidad de crear acciones y el de "poltica", ya que juega un papel muy importante lacapacidad de influir en los dems para que sigan sus instrucciones.

ASPECTOS A TENER EN CUENTA PARA EL DESARROLLO DEPROYECTOS

OPERAR DENTRO DE LAS REALIDADES DE LA VIDA ORGANIZACIONALNo es realista, disear y dirigir proyectos fuera de su contexto organizacional. Hay que tratar de trabajar eficazmente

con las realidades organizacionales en vez de luchar contra ellas.

El divorcio entre la responsabilidad y la autoridad:Casi siempre los Management de proyectos tienen poca autoridad para realizar su trabajo. Tienen escaso o nulocontrol sobre las personas y cosas que son importantes para el fracaso o xito del proyecto. Por lo general, supersonal es prestado y los recursos materiales necesarios oficinas, instrumentos cientficos, herramientas - debenser obtenidos de terceros.

Ello responde a la lgica, ya que por definicin: Los proyectos son temporales:por lo que es difcil asignar personas y recursos materiales con el rgimen

de tiempo completo.

Los proyectos son nicos:son estructurados para satisfacer necesidades momentneas.

Los proyectos son sistemas:es frecuente que en las distintas partes de un proyecto deban trabajarespecialistas y no es raro que cambien continuamente a medida que avanza el ciclo de vida del proyecto.

Fortalecer la Autor idad:Este aspecto es de mucha utilidad puesto que la autoridad es la capacidad para hacer que la gente nos tome enserio y cumpla nuestras rdenes. Para lograrlo hay que crear y fortalecer la base de autoridad, entre ellas podemosencontrar:

Autoridad formal: le es conferida con la designacin para dirigir el proyecto e indica un respaldo desdearriba. La calidad de autoridad formal que posea depender de si es una vaga sensacin o un respaldopblico y fuerte. En general, la escasa autoridad formal que tiene no es suficiente para contrarrestar otrasfuerzas que le impiden ejercer el control directo sobre RRHH y materiales.

Autoridad econmica:deriva de la autonoma presupuestaria y un buen uso de ella. Es til especialmentecon los agentes externos que dependen del pago de bienes y servicios que entregan. Es muy comn, sinembargo que se tenga poco control sobre el presupuesto, aunque puede ejercer autoridad econmica atravs del control de los recursos no monetarios, por ejemplo el tiempo de la gente, la asignacin deactividades y de prioridades y preferencias.

Autoridad burocrtica:su autoridad se basa en la comprensin de la importancia de llevar bien lospapeles, fijar plazos aparentemente arbitrarios para la presentacin de informes sobre la marcha delproyecto y conocer todos los detalles de la direccin de los trmites dentro de la organizacin.


12/200

Pg. 12 de 200

MANUALTCNICO

PMI-

IT



Estos tipos de autoridad derivan de las circunstancias organizacionales dentro de las cuales surgen. Examinaremos,ahora la autoridad que se origina en la personalidad y los mritos del especialista en proyectos.

Autoridad tcnica:los gerentes de proyecto que tiene autoridad tcnica, pueden hacer que la gente lesobedezca, no porque controlan sus salarios, sino simplemente porque respetan su capacidad tcnica. La

falta de esa capacidad tcnica puede impedir que una persona dirija determinados proyectos.

Autoridad carismtica: los profesionales de proyecto que tiene autoridad carismtica son capaces delograr que los dems los escuchen y cumplan sus rdenes por medio de la fuerza de su personalidad. Elmanager carismtico est convencido de su misin, tiene sentido del humor, tiene empata hacia lasnecesidades del equipo, es entusiasta y seguro de s. Es un lder.

La importanciade laautoridadesquesta leotorgaalprofesionalcierta influenciasobre losotrosagentesdelproyecto.Sinesainfluenciaelldernopodrcontrolarelproyecto.

EL AMBIENTE COMPLETO DEL PROYECTOLa visin del ambiente completo del proyecto revela una situacin que, desde el punto de vista de la direccin, es

sumamente compleja.El nmero de agentes con los que el director del proyecto debe tratar indica que todos tendrn que desempear unatarea compleja para llevar adelante el proyecto: un problema con cualquiera de los agentes puede hacerlodescarrilar.

Los directores de proyecto tienen que tratar no slo con el ambiente de la organizacin, sino tambin con suambiente interno. Tenemos entonces un ambiente de Management complejo. Las relaciones con los diferentesactores son tambin importantes, porque los problemas que surjan con cualquiera de ellos pueden poner en peligrola totalidad del proyecto. Pero tambin, la buena relacin con cualquiera de ellos ayudar enormemente al lder delproyecto. Examinemos con un poco ms de profundidad a estos agentes.

LOSALTOSEJECUTIVOS:el alto nivel gerencial de la organizacin puede estar directamente involucrado en

el proyecto o no. Eso depender de la magnitud del proyecto y su correspondiente visibilidad. Es posible queen proyectos de mayor visibilidad por su grado de significacin, los altos ejecutivos se sientan mas interesadosen participar.

ELJEFE:actualmente este concepto est siendo reevaluado. A medida que las organizaciones se apartan delas estructuras tradicionales y se vuelven hacia estructuras centradas en el trabajo en equipo, ya no queda tanen claro quin reporta a quin. La realidad es que los jefes todava existen y es preciso interactuar con ellos. Loms corriente es que sea el jefe quien decida que tarea desempearemos y quien trabajar con nosotros ennuestro proyecto.

LOSCOLEGAS:los otros gerentes de proyecto y la mayora de nuestros pares pueden ser amigos, enemigoso un poco de cada cosa. Pueden ser amigos porque son recursos tiles y pueden brindarnos importanteinformacin y porque pueden ser aliados para actuar dentro de la empresa.

Pero tambin pueden ser enemigos. Una fuente obvia de conflicto entre colegas es la escasez de recursos.Otra fuente de enemistad es la competencia por la carrera.

ELPERSONAL:casi siempre los empleados de los gerentes de proyectos son prestados: nunca se los asignaa un proyecto con dedicacin exclusiva y permanente. Por esta causa las actividades orientadas hacia elproyecto suelen organizarse con una estructura de matriz. Detrs del Management de matriz actan dosfuerzas impulsoras. Una es la eficiencia del empleo de los recursos, la otra es que permite darles a losproblemas soluciones transfuncionales. Los problemas complejos requieren el aporte de una vasta gama deagentes o actores.

LOSMANAGERSQUECONTROLANLOSRECURSOSINTERNOS:si los directores de proyectos tienenbuena relacin con esta categora de actores, tal vez puedan conseguir el mejor personal y equipamiento parasu proyecto pero, si no tiene buenas relaciones, quiz tropiecen con una real imposibilidad de obtener los

recursos humanos y materiales para realizar bien su trabajo.


13/200

Pg. 13 de 200

MANUALTCNICO

PMI-

IT



LOS CLIENTES INTERNOS: son individuos pertenecientes a la organizacin y tienen determinadasnecesidades, que sern satisfechas por medio de un proyecto de ejecucin interna.

LOS CLIENTES EXTERNOS: Son individuos u organizaciones del medio. Los proyectos satisfacen susnecesidades de dos maneras. La primera es que el proyecto se concentre en el desarrollo de un producto o

proceso que finalmente ser vendido a consumidores externos. Por otra parte, un proyecto puede satisfacer lanecesidad de un cliente externo a travs de un contrato. En tal caso los managers tienen una idea clara dequines son sus clientes y deben tener una buena comunicacin con ellos, para estar seguros de que quedarnsatisfechos.

ELGOBIERNO:los que trabajan en campos fuertemente regulados deben conocer las reglamentaciones queinfluyen sobre sus proyectos. En estos casos el manager de proyecto no slo enfrenta los problemas comunesa su campo profesional, sino que adems, debe trabajar bajo rgidas restricciones legales.

LOS SUBCONTRATISTAS:a veces una organizacin no dispone de todos los conocimientos y recursosnecesarios para acometer la realizacin de los proyectos que concibe. Los directores de proyecto que trabajancon subcontratistas deben controlar de cerca su desempeo, ya que el xito del proyecto depende en parte deellos.

LOSPROVEEDORES:muchos proyectos dependen en gran medida de productos que deben ser aportadospor proveedores externos a la organizacin. Para hacer un buen Management de proyectos es necesariocontar con proveedores confiables.

LA POLTICA DE LOS PROYECTOSLa poltica es el arte de la influencia. Los managers de los proyectos se parecen a los polticos. No son de por spoderosos, o sea, que carecen de la facultad de imponer directamente su voluntad sobre colaboradores,subcontratistas, proveedores. Si quieren abrirse paso deben ejercer influencia sobre las otras personas. Necesitantambin una aguda comprensin del ambiente general dentro del cual debe ejercitarse la autoridad.

El PMI BOOK define el proceso que sigue el buen poltico de proyecto, consta de seis pasos:1. EVALUARELAMBIENTE:al evaluar el ambiente el director de proyecto debe tratar de identificar a todos los

actores relevantes, estn involucrados directa o indirectamente. Una vez identificados todos los actores se tratade determinar dnde reside el poder.

2. IDENTIFICAR LOS OBJETIVOS: una vez identificados los actores, debemos determinar sus objetivos.Tenemos que tener en cuenta las posibles motivaciones psicolgicas, ya que muchas veces stas son msfuertes que las laborales. Al ocuparnos de los objetivos, obvios e implcitos, debemos poner especial atencinen los objetivos de los actores que tiene el poder, para determinar de qu forma debemos influir sobre ellospara que nos ayuden a concretar los objetivos del proyecto.

3. EVALUARLASPROPIASCAPACIDADES: los directores de proyecto deben tener una idea clara de susfuerzas y debilidades y deben ser capaces de determinar cmo influyen esas caractersticas sobre el proyecto.La autoevaluacin es un paso decisivo para elaborar una perspectiva realista del proyecto y su ambiente. Hay

dos capacidades que son fundamentales: trabajar bien con la gente y comunicar bien las propias ideas. 4. DEFINIRELPROBLEMA: el esfuerzo para definirlos debe ser sistemtico y analtico. Es preciso aislar y

examinar cuidadosamente los hechos que constituyen el problema y adems comprender los supuestosbsicos que sustentan el mtodo de definicin del problema.

5. DESARROLLARSOLUCIONES:es muy frecuente que el equipo del proyecto empiece por aqu. Empiezanpor ofrecer soluciones antes de haber entendido cabalmente el problema. Si embargo, si pueden ejercer unverdadero autocontrol y se abstienen de ofrecer soluciones prematuras las soluciones que elaboren tendrn elimportante mrito de ser realistas y pertinentes al verdadero problema.

6. VERIFICARYPERFECCIONARLASSOLUCIONES: las soluciones deben ser continuamente verificadas yperfeccionadas. Este sexto paso, se concentrar en dar los toques finales a las soluciones realistas elaboradas

inteligentemente.


14/200

Pg. 14 de 200

MANUALTCNICO

PMI-

IT



TRABAJAR CON GENTE CAPAZ

Cuestiones generales.La gente es el valor ms importante de un proyecto, ya que el fracaso o el buen xito del emprendimientodependern de la calidad de la gente que trabaje en l. Esto se refleja en el abandono de las jerarquas

impersonales que tanto dominaron el Management desde los albores de la revolucin industrial. Hoy se habla deempleados con responsabilidad, organizaciones planas y direccin de equipo. Actualmente se sostiene que lafuncin clave de los gerentes es apoyar, esdecir, crear un ambiente que les permita a los empleados trabajar lomejor posible. La tarea del manager es crear un ambiente en el que el equipo transfuncional pueda llegar a unconsenso eficiente sobre los cursos de accin que se van a seguir.

Quin manda aqu?Desde luego que la dispersin de la toma de decisiones a lo largo del proyecto puede producir confusin yconflictos. La toma de decisiones se distribuye a lo largo del proceso de realizacin de un proyecto cuando stedemasiado complejo para ser manejado en un estilo rgidamente jerrquico, con una cadena de mandos claramenteestablecida.

Los gerentes de proyecto no son jefes en el sentido convencional.

La figura ilustra este punto. Se ve all que los directores de proyecto son a menudo managers por excepcin. Elloquiere decir que se le da al equipo de trabajo amplia libertad de accin para tomas decisiones, dado que lasdecisiones individuales no afectan el presupuesto, el organigrama o la utilizacin de los recursos ni pueden producirproblemas polticos. Slo cuando es evidente que las cosas se le estn yendo de las manos, el director del proyectointerviene directamente en la toma de decisiones.


15/200

Pg. 15 de 200

MANUALTCNICO

PMI-

IT



SNo

SNo

S

No

S

No

El colaborador perfecto en un equipo de proyecto.El colaborador perfecto del proyecto cuenta con una caracterstica singular: un fuerte compromiso con el proyecto.Pero son pocas las personas que se comprometen a fondo con el proyecto; y eso se origina en dos fuentes: unaorganizacional y la otra, psicosocial.

La perspectiva organizacional.La estructura de matriz que impera en muchas organizaciones no favorece el compromiso personal con losproyectos.

El sistema de remuneracin de la estructura de matriz tampoco contribuye e generar incentivos para que unapersona dedique largas horas a su trabajo.

En estas circunstancias organizacionales no es sorprendente encontrarse con bastante reticencia de parte delpersonal del proyecto para comprometerse con el proyecto y trabajar horas extras. Adems muchas vecesparticipan en varios proyectos al mismo tiempo, lo que debilita an su compromiso.

La perspectiva psicosocial.Se trata de algo muy simple pero casi siempre ignorado: las personas que trabajan en proyectos sonmultidimensionales. Si los directores de proyecto tratan a la gente como si el trabajo fuese lo nico que lesimportara, tendrn que sufrir dos consecuencias: la primera, que estarn constantemente descontentos con suequipo y la segunda, que llegarn a pensar que las nicas personas que les convienen son las unidimensionales.

Trabajar con inteligencia.Casi todos los directores de proyecto concentran sus esfuerzos en lograr que su equipo trabaje ms.

Tendr una varianza depresupuesto inaceptable?

Me apartar demasiadode las especificaciones?

La cuestin que estoyapoyando es polticamente

sensible?

Toma de decisin

Tendr una varianza deorganigrama inaceptable?

GERENTE DEPROYECTO


16/200

Pg. 16 de 200

MANUALTCNICO

PMI-

IT



Pero tanto esfuerzo est, en general, mal orientado. En primer lugar, si el personal del proyecto no tiene un fuertecompromiso con l no lograrn que trabajen ms. Y, segundo, es tpico que el equipo de proyectos no seademasiado productivo, o sea, que no se trata de hacer que las personas trabajen ms duro sino de lograr quetrabajen inteligentemente.

Nuestros esfuerzos deben estar dirigidos a incrementar la productividad. Para trabajar con inteligencia debemosseguir ciertas reglas.

Hacer las cosas bien la primera vez: los gerentes de proyecto deben esforzarse al mximo para lograr que suscolaboradores hagan las cosas bien la primera vez. Cuando vemos que se estn haciendo las cosas ms deuna vez antes de llegar a la manera correcta hay una alta probabilidad que sea por un problemacomunicacional.

Fijar objetivos realistas: planifique de manera realista. No se ponga en situacin de depender de gente que noes con la que usted cuenta. La principal desventaja de esta solucin es que los gerentes de proyecto suelentener poca participacin en el proceso de planificacin. Una vez iniciadas las conversaciones, si el futurodirector advierte que el plan es demasiado optimista, puede tratar de renegociarlo. Si ese recurso fracasa,entonces tendr que presionar al equipo.

Conseguir gente tcnicamente competente: con frecuencia la baja productividad no se debe a que no contamoscon la colaboracin de superhombres y supermujeres, sino a que los empleados que realizan las tareas no son

tcnicamente competentes.

Tipos psicolgicos.En Management disponemos de una amplia batera de tests, preparados por psiclogos, que nos ayudan a entenderpor qu las personas se comportan de un modo y no de otro. Se los usa para diferentes fines: contratar personal,asignar a cada persona una tarea compatible con su personalidad, determinar las destrezas de cada uno, librarse delos trabajadores que no progresan y ayudar a todos a hacer autocrtica.

El test ms til para los directores de proyecto es el Myers- Briggs Type Indicator (Indicador tipolgico de Myers Briggs).

Este mtodo categoriaza a la gente segn cuatro escalas, cada una de las cuales refleja una dimensin delcomportamiento humano. Esas cuatro escalas dan lugar a diecisis casilleros donde es posible ubicar a unapersona.

Si conocemos el tipo psicolgico de alguien, podemos inferir rpidamente cmo se comportar en determinadacircunstancia. Esa informacin es til para los gerentes de proyecto, que deben tratar constantemente con muchaspersonas diferentes en toda clase de circunstancias.

LA DIMENSIN EXTROVERSININTROVERSIN: segn el esquema Myers-Briggs, un extrovertido esalguien orientado hacia el mundo exterior, el mundo de las personas y las cosas; y un introvertido es alguienorientado hacia el mundo interior, el de los conceptos y las ideas. Los extrovertidos suelen ser prcticos, lesgusta hacer varias cosas al mismo tiempo. Los introvertidos son propensos a vivir sobre todo en su mente.Piensan con ms profundidad que los extrovertidos.

LADIMENSINSENSITIVIDADINTUICIN:los individuos sensitivos atienden sobre todo a las sensaciones.Se preocupan mucho sobre los hechos, es decir, por los datos reunidos directamente a travs de los sentidos.Los intuitivos, recogen informacin a travs de sus sentidos y despus la procesan. No les preocupan loshechos en s mismos, sino las posibilidades que sugieren. Son imaginativos, se interesan ms por cmopodran ser las cosas que por cmo son realmente.

LADIMENSINRACIONALIDADAFECTIVIDAD:las personas perciben la realidad y despus emiten juiciosacerca de su significado. Algunos lo hacen a travs de un proceso fro y desligado: son los racionales. Estosindividuos se sientes ms cmodos en contacto con las cosas y los conceptos que con la gente. Tambin haypersonas que basan sus juicios en consideraciones ms subjetivas, en respuestas que salen del corazn. Sesienten ms cmodas en contacto con la gente que con las cosas. Son los afectivos.


17/200

Pg. 17 de 200

MANUALTCNICO

PMI-

IT



LA DIMENSINJUICIOPERCEPCIN: en esta dimensin se examina hasta que punto las personas sesienten obligadas a sacar conclusiones en el mundo circundante. Algunos individuos formulan un juicioinmediatamente. Siempre toman una decisin con rapidez; jams la postergan. Se sienten cmodos dentro delorden y la planificacin. El aspecto negativo es que suelen ser rgidos y estrechos de miras y corren el riesgode emitir juicios prematuramente. Son los juzgadores.

En cuanto al otro tipo, est compuesto por gente que prefiere diferir la emisin de un juicio hasta contar con msinformacin. Estas personas son flexibles y abiertas. Corren el riesgo de ser desorganizadas y de caer en la trampade la postergacin, porque siempre estn esperando recabar ms datos. Son los perceptivos.

Cmo aplicar a los proyectos la teora de los tipos psicolgicos.Conocer el mtodo de Myers-Briggs constituye una gran ayuda para los directores de proyecto, quienes podrn asmanejar mejor a la gente en varias reas importantes:1. Cmo seleccionar el personal.2. Cmo diagnosticar las races del conflicto.3. Mejorar las relaciones con el equipo.4. El autoconocimiento.

EL GERENTE DE PROYECTOLas responsabilidades principales del gerente de proyecto son las siguientes:

DESARROLLARELEQUIPO:el know-how del director de proyecto se transmite informalmente. Los gerentesaprenden a llevar adelante proyectos simplemente trabajando en ellos y mirando a otros ms experimentados.Si uno quiere que la gente haga las cosas bien, hay que ensearles cmo realizar sus tareas. Cuando acta asse est desarrollando el equipo.

ACTUARCOMO INTERMEDIARIOENTRELOSDIRECTIVOSYELEQUIPO: los gerentes de proyectotiene por encima a los altos niveles del Management y por debajo a los empleados. Por un lado forman partedel plantel ejecutivo. Son el canal a travs del cual fluye la informacin desde los directivos hacia losempleados. Por otra parte, los gerentes de proyecto forman parte del plantel de empleados y les brindan a los

ejecutivos una visin de las necesidades, capacidades y deseos de los empleados.

TRANSMITIRLOAPRENDIDO:los directivos de proyecto son la reserva de conocimientos prcticos. Suelenser tiles a sus organizaciones transmitiendo lo que han aprendido a sus pares, a los directivos y a losempleados. Estos conocimientos se transmiten generalmente de manera informal durante reuniones informaleso cuando se les pide un consejo.

EL ESTILO DE DIRECCIN.Cuando hablamos de estilo de direccin nos referimos a la manera en que los gerentes interactan con su equipo.

Analizaremos por separado los tres estilos separadamente en funcin de los flujos de informacin.

LOS

GERENTES

AUTOCRTICOS: a ellos no les interesa procesar la informacin que viene de afuera nitampoco les interesa la realimentacin proveniente del equipo.

El estilo gerencial autocrtico tiene sus pros y sus contras. Entre las ventajas podemos decir que el mtodoautocrtico es adecuado para los proyectos de rutina y de bajo riesgo, en los que el equipo se limita a llevaradelante el plan como fue establecido. Es eficaz cuando es preciso tomar decisiones rpidamente. Una desventajaes que el enfoque autocrtico lleva a la desmoralizacin del equipo, ya que los colaboradores no pueden hacerninguna contribucin importante al proceso de toma de decisiones. Puede llevar a tomar decisiones errneas, yaque el jefe no recibe suficiente informacin desde el exterior.

ELLAISSEZFAIRE:LOSGERENTESPERMISIVOS: nos encontramos con escaso flujo de informacin ocon un flujo de informacin aleatorio, que no se canaliza adecuadamente.


18/200

Pg. 18 de 200

MANUALTCNICO

PMI-

IT



En un sistema permisivo, el equipo del proyecto debe ser capaz de realimentar a los managers; perolamentablemente los managers no suelen actuar bien respecto de esa realimentacin.El mtodo permisivo puede ser eficaz en proyectos innovadores, en los que los directores fomentan lacreatividad y son reacios a imponer sus propios puntos de vista. Si examinamos las desventajas de esteenfoque veremos que puede llevar a la desorganizacin por falta de direccin. Otra importante desventaja esque resulta simplemente desastroso cuando es preciso tomar decisiones rpidas.

LOS GERENTES DEMOCRTICOS: antes de tomar decisiones, los gerentes democrticos tratanactivamente de recibir informacin originada en el equipo.

El mtodo democrtico facilita la toma de buenas decisiones, ya que refleja un amplio espectro de puntos devista. Incrementa el compromiso del equipo de implementar las decisiones ya que el conjunto de sus miembrosparticip en el proceso decisorio.

Una de las desventajas, es algo que los cientficos polticos llaman la tirana de la mayora. Esto se producecuando en un sistema democrtico siempre se impone determinada mayora, en desmedro de lo que pasa aser una perpeta minora.

La segunda desventaja se pone en evidencia cuando se confeccionan encuestas con los votantesequivocados y, en consecuencia, se toman decisiones sobre la base de una informacin incorrecta. Unatercera desventaja es que puede ser intil cuando es preciso tomar decisiones rpidas.

CMO ELEGIR UN ESTILO DE MANAGEMENT.En las situaciones reales de proyecto no es posible ni aconsejable que los directores adhieran a un estilo el cientopor ciento del tiempo. Los buenos gerentes adaptan su estilo para que reflejen las circunstancias que enfrentan.

El estilo empleado por el director de proyecto puede llegar a tener enorme influencia sobre los resultados. El secretoconsiste en saber qu estilo aplicar segn las circunstancias. Esa decisin depende, en gran medida, del sentidocomn del director del proyecto y de su capacidad para evaluar correctamente las situaciones.

ESTRUCTURAR LOS EQUIPOS DEL PROYECTO Y DARLES COHESIN.Los equipos son la unidad de trabajo de los proyectos. Un equipo es un conjunto de personas que trabajan juntaspara alcanzar determinado objetivo. Sus esfuerzos deben ser coordinados.

En los equipos de proyecto sucede con frecuencia que los miembros son tomados en prstamo de otros lugares yslo participan brevemente del trabajo en conjunto. Trabajan en una parte del proyecto y, cuando terminan, pasan aotro. Debido a esto, suelen no sentirse como parte de un equipo. No pueden desarrollar el espritu de equipo, esdecir el compromiso con el proyecto.

Una de las tareas ms importantes de los gerentes de proyectos consiste en desarrollar en su plantel cierto sentidode identificacin con el equipo.

La estructura del equipo tendr un fuerte impacto en las posibilidades de xito de un proyecto. Un equipo bien

estructurado es una condicin necesaria, pero no suficiente, para alcanzar el xito e incrementar la eficiencia. Encuanto al equipo mal estructurado, es una frmula segura para fracasar.


19/200

Pg. 19 de 200

MANUALTCNICO

PMI-

IT



LA EFICIENCIA DEL EQUIPO.Definimos a la eficiencia del equipo como la fraccin de desempeo potencial del equipo que se logra realmente. Nonos preocupamos por medir con exactitud la eficiencia del equipo sino por alcanzarla. Podemos decir que un equipode proyecto es ineficiente porque su diseo bsico causa ineficiencia o porque la friccin organizacional impide queopere con la suavidad que podra operar. Las principales fuentes estructurales de ineficiencia de un equipo de

proyecto son:

FRICCIONESBASADASENLAMATRIZ:en un proyecto de estructura de matriz la falta de continuidad delplantel es siempre causa de ineficiencia. La friccin organizacional es alta porque la gente pasa una importanteparte de su tiempo de trabajo revisando lo que han hecho otros. Si consideramos este hecho con la falta decompromiso caracterstica de los proyectos con personal de rotacin frecuente, veremos que la ineficienciaser baja. Otra importante fuente de friccin en un proyecto de matriz es que el manager carece de controldirecto sobre el plantel y sobre los recursos materiales.

MALA COMUNICACIN: examinaremos ahora tres de las diversas clases de friccin basadas en lacomunicacin.

1. LA COMUNICACIN COMO FIN Y NO COMO MEDIO:a medida que los proyectos se burocratizan, se invierte ms y ms

esfuerzo en transmitir informacin y coordinar tareas. Cuando se dedica demasiado tiempo a enviar y recibirmensajes, la eficiencia del equipo empieza a disminuir.

2. ARTERIOSCLEROSIS DE LA INFORMACIN:se produce cuando los canales de comunicacin estn tan obstruidos que lainformacin importante apenas si puede circular. La obstruccin es consecuencia de la exigencia de que lainformacin sea procesada de manera burocrtica. Tambin pude ser causada por grandes cantidades deinformacin intil que circula por los canales y bloquea el flujo de mensajes importantes. Frente a esto vemosque el trabajo en equipo se ve perjudicado.

3. MENSAJES DISTORSIONADOS:en los proyectos, las instrucciones que llegan distorsionadas pueden lograr que elequipo realice mal su trabajo. Si ese trabajo tiene que hacerse nuevamente o si causa problemas en otrasreas, la eficiencia del equipo diminuye. La comunicacin entre los clientes del producto y el equipo es tambinmuy importante. Si las necesidades de los clientes son mal transmitidas al equipo, el producto final ser

rechazado.

MALAINTEGRACIN:los directores del proyecto deben integrar las piezas, reunir todos los elementos paraque el proyecto y el producto funcionen correctamente. Si la integracin no se lleva adelante correctamente,aparecern grandes deficiencias en el proyecto. En cuanto a los directores de proyecto, en la medida en quesean eficaces integradores del sistema, aumentarn drsticamente la eficiencia de su equipo detrabajo.

COMO ESTRUCTURAR LOS EQUIPOS.Para estructurar equipos de proyecto de modo de incrementar la eficiencia del trabajo, debemos evitar lasestructuras que producen fricciones organizacionales que hemos mencionado.

No hay una sola estructura adecuada para todos los proyectos. Al configurar la estructura de un equipo es precisotener en cuenta varias cosas: Tamao del proyecto. Disposicin de personal permanente o si se producen rotaciones frecuentes. Aspecto tcnico del proyecto. Caractersticas de la cultura organizacional. Caractersticas psicolgicas de los miembros del equipo y otras personas involucradas.

LAESTRUCTURAISOMRFICA.Se dice de dos cosas que son isomrficas cuando comparten la misma apariencia estructural. Si configuramos unequipo de proyecto de modo que refleje fielmente la estructura fsica del producto, lo que se est produciendo, elequipo y el producto sern mutuamente isomrficos.


20/200

Pg. 20 de 200

MANUALTCNICO

PMI-

IT



Con un proyecto as estructurado se corre el riesgo de que las partes no encajen bien, ya que se las desarrolla porseparado.La principal funcin del gerente de proyecto ser servir de integrador.

Las ventajas del enfoque isomorfico son: Es organizacionalmente simple. Los diferentes mdulos del sistema son independientes, el mtodo isomrfico permite una implementacin de

las tareas en paralelo, lo que acorta considerablemente el tiempo de realizacin del proyecto. Es adecuado para los proyectos en los que hay miembros de equipo que estn trabajando por primera vez en

un proyecto. Su simplicidad facilita la integracin de los novatos a su ambiente.

LAESTRUCTURADELEQUIPOPORESPECIALIDAD.Siguiendo este mtodo se les pide a los miembros del equipo que apliquen sus conocimientos especficos adiversas tareas. Por lo tanto, el conocimiento es usado donde conviene hacerlo. Con este mtodo, los gerentes deproyecto se enfrentan al clsico dilema del Management de matriz: tienen un alto nivel de responsabilidad perocarece del correspondiente nivel de autoridad.

Algunas de las deficiencias de la estructuracin de los equipos por especialidad son: la responsabilidad es muydifusa y la distribucin del trabajo es desigual. La estructura por equipo por especialidad tiene tambin ventajas.

Requiere un nivel bastante elevado de autogestin. En cuanto a la toma de decisiones, sta se desplazanotablemente desde el gerente de proyecto hacia los miembros del equipo. Los conocimientos se aplican donde esconveniente hacerlo.

LAESTRUCTURADELEQUIPOSINEGOCENTRISMO.Si observamos un producto desarrollado por un equipo sin egocentrismo, o sea el resultado de un trabajo deverdadera colaboracin, no podremos discernir quin produjo qu parte. La estructura del equipo no egocntricofomenta altos niveles de interaccin y comunicacin entre los colaboradores.Si la comunicacin es buena y si losmiembros del equipo trabajan juntos hacia un objetivo comn, los problemas de integracin de sistemas sernpocos.Una de las crticas ms frecuentes es que el equipo no egocntrico no funciona porque cada persona tiene su propioego.Los directores y colaboradores de proyecto sienten orgullo por su autora, quieren hacer contribuciones nicas,destacarse entre la multitud. Otra de las crticas se refiere a la falta de liderazgo.

En ciertas situaciones, los equipos no egocntricos pueden trabajar de manera eficaz en las culturas occidentales.El equipo debe ser relativamente pequeo, ya que en los equipos grandes los canales de comunicacin sonnumerosos y ello produce burocracia y sus correspondientes ineficiencias.

Segundo, los equipos no egocntricos requieren que los colaboradores tengan continuidad: en ese aspecto separecen mucho a un equipo deportivo. Tercero, los equipos no egocntricos pueden funcionar bien en proyectos devanguardia en los que al principio el producto final est definido vagamente.

Los equipos no egocntricos suelen ser eficaces en proyectos en los que susmiembros, sumamentecreativos, se resisten a aceptar un liderazgo fuerte porque va en contra de sus principios y porquerestringe lacreatividad.Elconceptodeequiponoegocntricoesparticularmente interesantehoyen

da,

porque

muchos

de

sus

principios

bsicos

reviven

en

el

concepto

de

equipos

auto

gerenciados.

LAESTRUCTURADELEQUIPOQUIRRGICO.En la direccin de proyecto se le da a un individuo la responsabilidad total de llevar adelante el cuerpo principal deltrabajo de proyecto y se lo resguarda de presiones administrativas. En cuanto a la estructuracin de equipos, elmtodo quirrgico es diametralmente opuesto al no egocntrico. En el primero, toda la atencin se concentra en unsolo individuo y en su capacidad. En el segundo, lo que cuenta en el trabajo general del grupo.

El mtodo del equipo quirrgico tiene una ventaja importante: que elimina el problema de la integracin de lossistemas. Como el producto del proyecto fluye directamente de la mente de un solo individuo, es muy probable quelas partes encajen perfectamente.El mtodo quirrgico tiene una desventaja importante: que para desempear el papel de cirujano requiere unindividuo enormemente capaz. Y si no se dispone de una persona as, el producto resultante puede ser mediocre.

Otra desventaja es que bien puede suceder que el equipo termine por tener tres jefes. El cirujano, sin duda, un jefe,


21/200

Pg. 21 de 200

MANUALTCNICO

PMI-

IT



pero sobre todo en lo concerniente a las cuestiones tcnicas. El administrador del proyecto tambin es jefe, porqueest a cargo del mantenimiento y el control de presupuestos, cronogramas y asignacin de recursos materiales. Y,por ltimo, el asistente personal est absolutamente en condiciones de asumir la responsabilidad de coordinar ycontrolar al personal tcnico especializado. Si estos tres individuos no se comunican entre s clara y frecuentemente,o si tienen ideas diferentes sobre los objetivos del proyecto, la eficiencia del equipo ser baja.

El mtodo del equipo quirrgico es muy eficaz en proyectos de diseo, de programacin de computacin y en losque implican gran cantidad de redaccin de textos. Tambin puede ser usado en proyectos grandes si se le da estaestructura a cada uno de los mdulos.

La estructura del equipo tiene enorme influencia sobre su desarrollo y desenlace. No hay una sola estructuraperfecta para dirigir proyectos. Es conveniente que el equipo del proyecto estudie la arquitectura de la organizacin;as desarrollar paulatinamente la capacidad de predecir muchas de las cosas que suceden en los proyectos ya quegran parte de todo ello tiene que ver con la estructura.

COMO CREAR LA IDENTIDAD DE UN EQUIPO.A los gerentes de proyecto les interesa especialmente estimular el sentido de identidad entre sus colaboradores.Hay muchas maneras de lograrlo. Muchas veces el estilo del manager, su personalidad, unifican al equipo. Los que

carecemos de un excepcional carisma debemos esforzarnos mucho para desarrollar un sentimiento de identidadentre los miembros del equipo. La tarea de armar un equipo debe centrarse en tres tpicos:

1. LOGRARQUEELEQUIPOSEAALGOTANGIBLE: todos los gerentes de proyecto tratan de hacer tangiblessus equipos. Algunos recursos para esto son: organizar reuniones, conseguir un espacio fsico para el trabajogrupal, darle un nombre al equipo.

Usar bien las reuniones: el propsito ms evidente de las reuniones de equipo es comunicar lainformacin. Una funcin menos obvia consiste en establecer una identidad de equipo concreta. Aliniciarse un proyecto se organiza la reunin de lanzamiento que hace tangible al grupo. Si es posible, debeestar presente un ejecutivo de alto nivel, para demostrar claramente el compromiso de los directivos con elproyecto. Otra reunin importante es la de revisin del estado del trabajo. Se trata de reuniones peridicasen las que se evala el desarrollo del proyecto.

Lugar fsico de trabajo:la manera ms obvia de hacer tangible al equipo es reunir a los colaboradores enun espacio comn. Hay que establecer un cuartel general puesto que sirve como seal tangible de laexistencia del equipo. Aun cuando se encuentre apartado del mbito de sus actividades cotidianas, loscolaboradores asociarn al equipo con el cuartel general.

Darle nombre al equipo:otro recurso para dar vida concreta al equipo es bautizarlo. Muchas veces se creatambin un logotipo.

2. CREARUN SISTEMADE RECOMPENSAS: sin incentivos, es difcil motivar a los colaboradores de unproyecto. Como los miembros del equipo de proyectos no participan del sistema de recompensas y castigos dela institucin deben inventar uno propio. Algunas sugerencias son: Cartas de recomendacin: los gerentes de proyecto pueden escribir cartas de recomendacin que luego

podrn ser incorporadas en los legajos personales. Reconocimiento pblico por buen desempeo: los mejores colaboradores deben ser felicitados por su

trabajo, no slo al final del proyecto, sino en diversas ocasiones. Asignacin de tareas: puede ser utilizada para recompensar y castigar a los miembros de un equipo. El

buen desempeo se puede recompensar con la retribucin de una tarea estimulante e importante. Horarios flexibles: los buenos colaboradores pueden ser recompensados con cierta flexibilidad en la carga

horaria. Beneficios segn el desempeo: la mayora de las organizaciones otorga ciertos beneficios como

incentivos: espacio especial en el estacionamiento, derecho a utilizar un vehculo de la empresa, oficinaconfortable, etc.

Nuevo equipamiento: cada vez que se reciba nuevo equipamiento, las mejores piezas se distribuirn entrelos colaboradores ms destacados, como seal de reconocimiento por sus esfuerzos (este recurso esespecialmente eficaz con personal tcnico).


22/200

Pg. 22 de 200

MANUALTCNICO

PMI-

IT



Recomendacin para la asignacin de bonificaciones: los mejores empleados reciben bonificaciones endinero efectivo. Desde luego, los directores de proyecto deben apoyarse en esta posibilidad para motivar asu gente.

3. DARUNTOQUEPERSONALALEQUIPO: el tercer recurso para construir un sentimiento de identidad deequipo consiste en utilizar bien el toque personal, la relacin directa entre los gerentes y su personal prestado.

La lista que un gerente puede hacer para reforzar su toque personal es interminable. Se ha demostrado que lassiguientes acciones son eficaces para construir un espritu de equipo en los proyectos: ser solidario, ser claro,informarse acerca de los miembros del equipo, celebrar las ocasiones especiales, ser accesible, entre otrascaractersticas.

ASEGURARSE DE QUE EL PROYECTO SE BASE SOBRE UNANECESIDAD CLARA

EVOLUCIN DE LAS NECESIDADES.Las necesidades son la fuerza motriz fundamental que impulsa los proyectos. El surgimiento de una necesidaddesencadena el proceso del proyecto. Si al comienzo no comprendemos totalmente una necesidad y susconsecuencias, si la formulamos incorrectamente, o si por error abordamos una necesidad equivocada, habremosdado origen a un mal comienzo y podemos estar seguros de que nuestro proyecto estar lleno de problemas.

EL CICLO DE VIDA DE LAS NECESIDADES Y LOS REQUERIMIENTOS.En primer lugar, hay una fase de aparicin de las necesidades. Existe despus una fase de reconocimiento de lasnecesidades. Esto es seguido a su vez por una fase de formulacin de las necesidades. Una vez expresadas, lasnecesidades pueden servir de base para establecer los requerimientos funcionales (descripcin detallada de lo queun proyecto tendra que hacer para satisfacer las necesidades que se han formulado). A partir de estosrequerimientos, se pueden formular los requerimientos tcnicos.

1. APARICIN DE LAS NECESIDADES.

El cambio es el generador de las necesidades. Como vivimos en una era caracterizada por el cambio, debemosenfrentar constantemente la aparicin de nuevas necesidades. Las necesidades pueden surgir desde adentro odesde afuera de una organizacin. Las necesidades internas por lo general se relacionan con la mejora deldesempeo organizacional.

2. RECONOCIMIENTO DE LAS NECESIDADES.Sin embrago, no basta con que slo surjan necesidades. Esas necesidades deben ser reconocidas. Si no, no seemprender accin alguna para satisfacerlas. No es fcil detectar las necesidades nuevas. El reconocimiento de lasnecesidades requiere un esfuerzo consciente. La gente de las organizaciones debe preguntarse constantemente:

cules son nuestras necesidades? Cules son las necesidades de nuestros clientes?

Podemos afirmar que no basta con concentrarse en las necesidades del momento, sino que es preciso prever lasque surgirn. Esto se hace en base al plan estratgico de la organizacin, y el plan estratgico de TI.

3. FORMULACIN DE LAS NECESIDADESUna vez reconocida la necesidad, es preciso formularla claramente. Esta formulacin implica un examen profundode la necesidad reconocida. Por medio de ese examen nuestra comprensin de la necesidad cambiar. Laformulacin de las necesidades tiene, adems, un costado prctico: sirve de base para el desarrollo de losrequerimientos funcionales.

En la prctica, las necesidades pueden ser formuladas de muchas maneras diferentes. Uno de los mtodos posiblespara formular eficazmente las necesidades consta de los siguientes cinco pasos:

Paso 1: pedirles a las personas que experimentan la necesidad que la definan lo ms claramente posible. Es

importante ver la necesidad a travs de los ojos de los clientes, aunque, por lo general, tienen una idea bastante


23/200

Pg. 23 de 200

MANUALTCNICO

PMI-

IT



vaga de la necesidad. Para ello existen plantillas de captura de informacin o definicin de procesos que permitenestablecer las necesidades y as poder documentarla y evaluarla en base a la ptica del cliente, por ejemplo lametodologa PDCA tienen plantillas de captura muy tiles y fciles de usar.

Paso 2: formular una batera de preguntas acerca de la necesidad. Estas preguntas nos obligarn a encarar lanecesidad de distintos puntos de vista. Y al responderlas nos brindar una visin multidimensional.

Paso 3: realizar toda la investigacin necesaria para comprender mejor la necesidad. Antes de que estemos encondiciones de formular claramente una necesidad, es preciso que la entendamos en todos sus aspectos,incluyendo los tcnicos. Es conveniente realizar una exposicin de nuestra ptica y comprensin de la necesidadantes el usuario o cliente interno que realiza el requerimiento de la necesidad para que el determine si entendemossu punto de vista y si le entregaremos lo que el espera.

Paso 4:en vista del conocimiento obtenido en los primeros tres pasos, formule la necesidad lo mejor que pueda.

Paso 5:pdales a los clientes que comenten su formulacin de la necesidad, y despus revsela. Durante el ciclovital de las necesidades y los requerimientos, es muy comn que los expertos modifiquen las necesidades para quelos satisfagan a ellos y no a los clientes. Para reducir al mnimo la posibilidad de que esto suceda, la persona que

formula las necesidades debe hacer un gran esfuerzo para asegurarse de que lo que ha articulado refleja realmentelas necesidades de los clientes. Esto puede lograrse trabajando en estrecho contacto con los clientes.

4. REQUERIMIENTOS FUNCIONALES Y TCNICOS.Una vez definidas cuidadosamente las necesidades, podemos utilizarlas como base para la elaboracin de un plande proyecto. Hacemos esto formulando las necesidades como requerimientos funcionales (describen caractersticasdel producto en lenguaje corriente, de modo que cualquier persona sin conocimientos tcnicos puedacomprenderlas).

Los requerimientos tcnicos surgen de los requerimientos funcionales (se escriben para el equipo tcnico). Laespecificacin de los requerimientos es una de las tareas ms difciles que deben realizar los planificadores y losgerentes de proyecto. Los requisitos inadecuadamente especificados producen siempre el fracaso o el maldesempeo del proyecto.

ASPECTOS DIFCILES EN LA DEFINICIN DE LAS NECESIDADES.De lo que hasta aqu se ha expuesto acerca del ciclo de vida de las necesidades y los requerimientos, se deduceque el proceso de definicin de las necesidades puede marchar mal por diversos motivos y en diferentes formas.Examinaremos tres categoras amplias de problemas.

1. CMOENCARARLASNECESIDADESNECESARIAMENTEVAGAS.La causa fundamental de la dificultad para definir las necesidades es que esas necesidades son inherentementevagas.

Hay dos caractersticas de las necesidades que contribuyen a su natural vaguedad: Necesidades dinmicas: la razn de que las necesidades sean de ndole dinmico es que siempre se las

define en relacin con el ambiente con el que surgen. Lamentablemente cuando las necesidades surgen ynosotros nos esforzamos por formularlas con precisin, el ambiente no se queda quieto, sino que siguecambiando.

Algunas fuentes especficas de modificacin de las necesidades son: Cambio de actores: cada vez que aparecen en escena nuevos actores, ellos traen consigo su

propia perspectiva del proyecto. Cambio de presupuesto: todos los gerentes de proyecto han tenido alguna vez la experiencia de

que se les asigne una partida presupuestaria para realizar determinado proyecto y despus esapartida sea retirada.

Cambio de tecnologa: cada vez que se introduce en el mercado una tecnologa nueva, esatecnologa estimula a la gente y la induce a replantearse sus necesidades.

Modificacin del ambiente comercial.


24/200

Pg. 24 de 200

MANUALTCNICO

PMI-

IT



Teniendo en cuenta la naturaleza dinmica de las necesidades, es una buena idea crear planes de proyectosflexibles.

Hay algo ms que los planificadores y los gerentes de proyecto pueden hacer: prever los cambios en lasnecesidades por medio de la prediccin. Al formular una necesidad, el gerente de proyecto no debe definirla enfuncin del ambiente existente, sino tambin en funcin del ambiente comercial futuro.

Entender mal las necesidades: a las necesidades se las percibe vagamente y, por lo tanto, no es posiblesatisfacerlas de modo eficaz, al menos mientras se las conciba de esa forma. Las implicancias de todoesto para los planificadores de proyecto son clara: si los gerentes basan sus planes slo en lasformulaciones de las necesidades del cliente, es casi seguro que no lograrn producir objetos quesatisfagan las verdaderas necesidades de sus clientes.

El equipo de proyecto debe reconocer que uno de los papeles ms importantes que ellos desempean es el de seruna gua para los clientes. Al trabajar en estrecho contacto con clientes, los miembros del equipo de proyecto debenayudarlos a identificar claramente lo que necesitan

2. IDENTIFICARLASSOLUCIONESPREMATURAMENTE.La inherente vaguedad de las necesidades es una trampa importante que acecha constantemente a losplanificadores de proyecto. Otro inconveniente muy comn consiste en abreviar el proceso de formulacin de las

necesidades, lo cual hace que produzcan respuestas antes de haber formulado las preguntas correctas.

El anlisisde las necesidades requiere unabuena dosis de paciencia y autocontrol.Con frecuenciaestamos dispuestos a ofrecer una solucin antes de haber entendido cabalmente la necesidad.

El reconocimiento y la formulacin de necesidades es un proceso evolutivo. Es importante que al comienzo dejemosabierta la mayor cantidad posible de opciones. A medida que hacemos el esfuerzo de formular las necesidades,obtenemos ms y ms informacin pertinente, lo que nos permite ir disminuyendo la cantidad de opciones. Slodespus de haber cumplido con todo este proceso dispondremos de informacin suficiente para considerar conseriedad las soluciones especficas que podran satisfacer nuestras necesidades.

3. ENCARARLASNECESIDADESDELOSCLIENTESEQUIVOCADOS.En las primeras etapas del ciclo vital de las necesidades y los requerimientos, debemos tratar de esclarecer quienesson las personas que experimentan esas necesidades.Si no, existen grandes posibilidades de que tratemos desatisfacer las necesidades de personas que no son las necesitadas.

Hay dos inconvenientes o engaos posibles: hay muchos clientes y nosotros encaramos la resolucin de lasnecesidades del sector equivocado de clientes. Y el segundo malentendido es que nuestros valores personalestian nuestra interpretacin de las necesidades del cliente, y terminamos encarando la satisfaccin de nuestrasnecesidades.

CMODISTINGUIRLASNECESIDADESDELOSDIFERENTESCLIENTES.Siempre hay muchos clientes involucrados, y sus necesidades por lo general no se superponen. Un planificador deproyectos debe distinguir las diversas necesidades, determinar cules son las ms importantes y construir un nuevoconjunto de necesidades que capte los rasgos ms importantes del conjunto general.Cuando se trabaja con muchos clientes la tarea de reconocer las necesidades y formularlas puede tornarsecompleja. Esto se debe al hecho de que hay ms necesidades. Estas diversas necesidades pueden entrar enconflicto, por lo tanto, es evidente que hay que establecer prioridades.

ESTABLECERPRIORIDADES:LAJERARQUADENECESIDADESLa jerarqua de necesidades es un diagrama que muestra toda la gama de necesidades para determinado problemay sus relaciones mutuas. Las necesidades que aparecen en un nivel incorporan las necesidades que aparecen en elnivel inferior siguiente. En todos los niveles de la jerarqua es preciso tomar decisiones para establecer prioridadesentre las necesidades encontradas en ese nivel.

Para elaborar los detalles de una jerarqua de necesidades, es preciso determinar el contexto de la situacin. Alconstruir una jerarqua, nos vemos obligados a actuar sistemticamente para identificar a los actores relevantes ysus necesidades. Tambin tendremos que tomar decisiones: establecer un orden de importancia. Y, por ltimo, sirecurrimos a un equipo bien elegido de anlisis transfuncional de las necesidades para que construya la jerarqua


25/200

Pg. 25 de 200

MANUALTCNICO

PMI-

IT



por medio de un proceso de consenso, incrementaremos tambin la posibilidad de que las necesidades formuladasreflejen las verdaderas necesidades de los clientes.

DISTORSIONARLASNECESIDADESDELOSCLIENTES.Siempre existe el peligro de que los individuos que analizan las necesidades alteren su formulacin a fin de reflejarsus propias tendencias y no las verdaderas necesidades de los clientes.

Las distorsiones pueden ser diversas. Las tres ms comunes son: DORAR LAS NECESIDADES:el problema de dorar las necesidades es muy comn en organizaciones que no

tienen grandes restricciones presupuestarias. Un proyecto concebido como simple y relativamente baratopuede llegar a ser complejo y caro si las necesidades se redefinen una y otra vez para incorporar todas las

contingencias posibles. Las organizaciones de recursos modestos no tiene gran tendencia a dorar lasnecesidades, no porque no les guste la tecnologa ms avanzada, sino porque la disciplina de la cuentaexigua, las obliga a ser prudentes.

FILTRAR SELECTIVAMENTE LAS NECESIDADES DEL CLIENTE: todos vemos el mundo a travs de un filtro que reflejanuestras experiencias, valores y conocimientos. Nuestros filtros tien nuestra percepcin de las cosas. Losproblemas empiezan cuando nuestras percepciones se desvan drsticamente de la realidad. En talsituacin nuestra respuesta a los problemas puede tener poca relacin con lo que se necesita pararesolverlos. La mejor manera de superar este problema es hacer que el reconocimiento y la formulacinde las necesidades sean aplicados por un grupo transfuncional. As las necesidades sern contempladasdesde diversos ngulos.

APLICAR AL RECONOCIMIENTO Y LA FORMULACIN DE LAS NECESIDADES EL MTODO LLAMADO PAP SABE LO QUE HACE: porlo general las personas que trabajan en la formulacin de las necesidades han sido seleccionadas para la

tarea porque tienen la experiencia y la competencia tcnica necesarias para traducir la percepcin de lanecesidad del cliente en algo concreto y viable. El agente asume una postura paternalista y piensa quesabe lo que es mejor para su cliente, aun cuando ese cliente se resista a aceptar sus sugerencias. En estasituacin, es muy probable, que el proyecto resultante de la formulacin que hagan desemboque en unproducto que ser mal interpretado, mal utilizado o simplemente no usado.

ESPECIFICAR LO QUE EL PROYECTO DEBE LOGRAR.Los malentendidos y los errores son una presencia constante en la vida cotidiana. Los proyectos tambin estnllenos de malentendidos entre el equipo y los clientes. Con mucha frecuencia lo que el cliente recibe no es lo quepidi o, exactamente, lo que creeque pidi.

Necesidad

Global

NecesidadNecesidadNecesidad

Necesidad Necesidad Necesidad

Necesidadessubsidiarias

Necesidadessubsidiarias


26/200

Pg. 26 de 200

MANUALTCNICO

PMI-

IT



La esencia misma de una importante fuente de malentendidos en los proyectos es la formulacin incorrecta de losrequerimientos del cliente. Los directores del proyecto deben esforzarse por reducir al mnimo posible el riesgo demalentendidos, y pueden lograrlo especificando cuidadosamente los requerimientos del cliente.

LA NATURALEZA DE LOS REQUERIMIENTOS.Los requerimientos especifican cmo debe ser el producto del proyecto, y pueden dividirse en dos categorasbsicas: requerimientos funcionales y requerimientos tcnicos.Los requerimientos funcionales describenlas caractersticas del producto en lenguaje corriente, no tcnico. Deben ser comprensibles para los clientes. Encuanto a los requerimientos tcnicos, describen las caractersticas del producto en lenguaje tcnico.

Las especificaciones del proyecto son importantes al menos por dos razones. En primer lugar, son la encarnacintangible de las necesidades del cliente. La planificacin del proyecto se reduce a determinar cul es la mejor manerade satisfacer las exigencias de las especificaciones. Y si stas son errneas o estn mal expresadas, el plan serdefectuoso.

En segundo lugar, las especificaciones son importantes porque definen las obligaciones que el equipo tiene paracon los clientes.

PROBLEMAS CON LOS REQUERIMIENTOS.Los problemas de especificaciones se producen por diversas causas: las especificaciones son incorrectas, sonimprecisas o ambiguas, cambian a medida que se desarrolla el proyecto. Independientemente de la ndoleespecfica de estos problemas, sus consecuencias se despliegan de manera alarmante.

Cuando surgen problemas con las especificaciones, los gastos se disparan y los organigramas colapsan, o losclientes quedan totalmente insatisfechos. Lo mejor es evitar los problemas antes de que aparezcan, porque una vezque aparecen es difcil resolverlos. Cmo evitarlos? Esforzndose al mximo por formular cuidadosamente lasnecesidades del cliente y trabajando despus en estrecho contacto con l para elaborar especificacionesfuncionales precisas, carentes de toda ambigedad.

1.REQUERIMIENTOSINCORRECTOS.

Las necesidades del cliente pueden ser mal interpretadas y mal expresadas, por diversos motivos y de diversasmaneras. Las especificaciones funcionales construidas a partir de necesidades mal expresadas no cumplirn suobjetivo. El producto final tendr escasa o ninguna relacin con lo que los clientes necesitan y desean. Veamos unresumen de los pasos que hay que dar para reconocer y articular correctamente las necesidades.

Primero, los directores del proyecto deben reconocer la dificultad intrnseca de la formulacin de las necesidades.Las necesidades suelen ser confusas, a veces ni siquiera quienes las experimentan son capaces de precisarlas. Elreconocimiento de la dificultad es importante, porque insta a los individuos encargados de formular las necesidadesa prestar gran atencin a su tarea.

Segundo, los planificadores de proyectos deben identificar quines son los clientes ms importantes.Tercero, los directores de proyecto deben trabajar en estrecho contacto con los clientes para poder formular lasnecesidades. Deben evitar el exceso y no deben imponer a los clientes sus propias necesidades ni asumir una

actitud paternalista y de superioridad.

2.REQUERIMIENTOSIMPRECISOSYAMBIGUOS.Cuando se plantean los requerimientos en trminos imprecisos y ambiguos, susceptibles de interpretacionesdiversas, es inevitable que haya graves problemas. Las especificaciones se formulan imprecisamente por diversasrazones. A continuacin se cita una lista de razones obvias para una especificacin imprecisa de los requerimientos.

LA NDOLE DEL LENGUAJE HUMANO.El lenguaje humano es naturalmente ambiguo. Pero esa ambigedad no es adecuada para describir lasespecificaciones del producto de un proyecto. Es arriesgado depender slo del lenguaje para describirespecificaciones. Para que las especificaciones sean precisas debemos aadir material complementario:dibujos, muestras, mapas, fotografas, datos tcnicos.IMPRECISIN DELIBERADA EN BENEFICIO DE LA FLEXIBILIDAD.


27/200

Pg. 27 de 200

MANUALTCNICO

PMI-

IT



A veces la ambigedad con que se formulan las especificaciones es deliberada y est destinada apreservar la flexibilidad del proyecto. Este mtodo se aplica sobre todo en los proyectos innovadores,cuando existe una gran incertidumbre con respecto del desarrollo. Se teme que una formulacin muyprecisa de los requerimientos limite el trabajo del equipo y desaliente el aprovechamiento deoportunidades inesperadas.

CONSENSO PARA EVITAR CONFLICTOS PERSONALES.Si las personas involucradas no pueden lograr consenso sobre lo que debe salir de un proyecto, tampocopodrn formular requerimientos precisos. Muchas veces pospondrn decisiones difciles, en espera que elconflicto que las separa se disuelva. En esos casos es probable que las especificaciones formuladas convaguedad asuman vida propia y lleven a la construccin de un producto que no satisfaga a nadie.PROYECTOS DE TECNOLOGA INFORMTICA SON INHERENTEMENTE NEBULOSOS.Los proyectos de tecnologa informtica y sistemas de informacin suelen tratar con temas intangibles osemi-tangibles. Para disear un proyecto manejamos fundamentalmente abstracciones. Pretender queuna firma capte estas abstracciones es como pretender aferrar un puado de arena.Para minimizar los problemas generados por la ndole inherentemente etrea de sus proyectos, losdirectores y equipos deben tratar de ayudar a los clientes a ver el resultado cuanto antes. Deben valersede herramientas visuales: dibujos, diagramas de flujo, tablas.Ya se ha creado una metodologa para ayudar a los planificadores y directores de proyectos a utilizar

eficazmente los prototipos en proyectos de informtica. Esametodologase llamaconstruccindeprototiposdeaplicacinoconstruccinrpidadeprototipos.LOS CLIENTES NO SON EXPERTOSUna de las tareas ms importantes del equipo de trabajo de un proyecto es ensearles a los clientes lascaractersticas ms importantes del futuro producto. Por cierto, no es de esperar que los clientes lleguen asaberlo todo. Cunto deben saber? En general, podemos decir que deben saber lo suficiente como parapoder hacer un aporte significativo a la formulacin de las necesidades y a la especificacin de losrequerimientos. Tambin deben saber lo suficiente para no sorprenderse con el resultado final. Teniendoen cuenta estas condiciones, la cantidad especfica de informacin que deben recibir ser determinadacaso por caso.DESCUIDOS POR PARTE DE LOS AUTORES DE PROYECTOSLa imprecisin de los requerimientos puede deberse a un mero descuido, ms que a prejuicios o malacomprensin del tema.Estas imperfecciones se producen en todos los proyectos, excepto en los ms rutinarios. En cierto modoes inevitable que as sea. Se producen porque todos actuamos segn supuestos tcitos y porque, comono somos omniscientes, carecemos de la imaginacin necesaria para identificar todas las contingenciasque podran afectar negativamente nuestro proyecto.Una manera de minimizar estos descuidos consiste en acudir a las personas que realizan las tareas ypreguntarles cules son las contingencias que podran surgir en las especificaciones del proyecto. Unbuen mtodo de largo plazo para encara estos inconvenientes consiste en compilar poco a poco, proyectotras proyecto, una lista de las especificaciones que deben ser tenidas en cuenta en todos los proyectos.

3.REQUERIMIENTOSCAMBIANTES.Los proyectos son dinmicos y, por lo tanto, no es sorprendente que, en el proceso de su desarrollo, surjan fuertespresiones para modificar los requerimientos, y puede producir un desborde de los costes y el incumplimiento de los

organigramas.Por ejemplo, el cliente se arrepiente, despus de mucha reflexin y grandes debates, se toma la decisin de lanzarun costoso proyecto; pero no bien empiezan los trabajos, los responsables cambian de idea. Tratan de reducir elproyecto, para as limitar las perjudiciales consecuencias que imaginan tendran que sufrir si el emprendimientofuera un fracaso. La reduccin puede ser muy costosa, sobre todo si el proyecto est adelantado.

Otro punto, es la aparicin de obstculos insalvables. Es una experiencia comn en ciertos proyectos. Todoproyecto innovador corre ese riesgo. Un ejemplo claro de esto es cuando a alguien se le prohbe continuarinvestigando sobre algo o se le deniega una determinada autorizacin para realizar algo vital para continuar con eldesarrollo del proyecto.

Muchas veces los cambios en las especificaciones (raptos de fantasas) pueden llevar a la concrecin de un

producto superior, tambin pueden crear graves problemas para el gerente de proyecto.


28/200

Pg. 28 de 200

MANUALTCNICO

PMI-

IT



Por otra parte, los cambios en las especificaciones tienen un coste econmico. Debido a ellos los plazos se alargan,los gastos aumentan y es preciso posponer o cancelar otros proyectos que esperaban ser realizados. Si seintroducen cambios constantemente, el proyecto corre riesgo de no llegar a realizarse nunca.

Es delgada la lnea que separa la fantasa de la oportunidad. No obstante hay entre ambas una diferenciaimportante. Los raptos de fantasa implican casi siempre un desordenado impulso a cambiar las especificaciones,sin tener en cuenta costes, organigramas ni recursos. Quienes practican habitualmente este mtodo de desarrollode proyectos confunden planificacin con realizacin ad hoc. Proponen una escuela de direccin de proyectobasada en la idea de planificar a medida que se avanza.

Por el contrario, el aprovechamiento de las oportunidades implica una respuesta mesurada ante los desarrollosimprevistos; implica capitalizar lo inesperado. Para que este enfoque tenga xito hay que asegurarse de que elbeneficio del cambio de especificaciones supere al aumento de los costes.

Es fcil y natural que los requerimientos cambien. A veces el cambio es para mejor y produce una mejora delproducto. Pero en otras ocasiones es meramente una perturbacin y slo produce demoras e injustificadosaumentos en los costes.

Una vez que los profesionales han identificado los posibles cambios deben aprender a prever sus consecuencias.Sin una metodologa consciente para encarar los cambios en las especificaciones, el equipo no llegar a tener unverdadero y real control de su proyecto.

LANEGOCIACINENLAESPECIFICACINDELOSREQUERIMIENTOS.Las personas encargadas de especificar los requerimientos de un proyecto d

33483080 Administracion y Gestion de Proyectos Informaticos

Documents

Transcript of 33483080 Administracion y Gestion de Proyectos Informaticos