Administracion y Gestion de Proyectos Informaticos

wwww.itcpcerbesa.
com
METODOLOGA PARA LA ADMINISTRACIN Y GESTIN DE PROYECTOS INFORMTICOS.
MANUAL TCNICO
Cristian Bailey Consultor IT
Pg. 1 de 200
MANUAL TCNICO PMI - IT
wwww.itcpcerbesa.com
INTRODUCCIN:
Generalmente las personas perciben a la informtica como una ciencia capaz de hacer castillos sobre el aire, y que todas sus ideas se podrn representar en un desarrollo de Software determinado, pero al darse cuenta que los ideales concebidos por ellos tienen un costo e involucran una serie de acciones resultan cambiando de opinin, es por 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 necesidades y los respectivos entregables que recibir el antes mencionado es donde radica el xito o fracaso de un proyecto de informtica. Al tener bien definidas las dimensiones de las necesidades y entregables del cliente, los costes del proyectos sern mas certeros (siempre y cuando no surjan cambios en el transcurso del proceso) y los tiempos de entrega sern exactos. A lo largo del manual tcnico se describirn tres grandes reas que componen la administracin de proyectos en el rea 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 conocimientos generales de las tcnicas recomendadas por PMI en el PM BOOK para la correcta gestin de proyectos. En resumen 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 pueden obviar 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 la relacin 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 de estndares de seguridad informtica.
REFLEXIN: "Lainnovacinesloque distingueallderdesus seguidores" MANUAL TCNICO PMI - IT Cristian Bailey Consultor IT Pg. 2 de 200
CAPITULO 1 LA ADMINISTRACIN DE PROYECTOS.
"Unbuenldernoesaquelquehacetemblarasussubordinados,unbuenldersehacerespetar porsuscolaboradores"
Pg. 3 de 200
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 esforzamos conscientemente por dominarlos o dirigirlos. El Management de Proyectos es de desarrollo reciente, como esfuerzo consciente por coordinar lo ms eficientemente posible un presupuesto, un plan y los recursos en juego, para entregar el proyecto en tiempo y calidad requerida.
QU ES UN PROYECTO?
Es la bsqueda de una solucin inteligente a un problema tendiente a resolver, fundamentalmente, necesidades humanas. Es la combinacin de todos los recursos necesarios, reunidos en una organizacin temporal, para la transformacin de una idea en una realidad. Previamente a la realizacin de cualquier proyecto es preciso estudiar seriamente la viabilidad, la utilidad econmica y 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:
Estn orientadas hacia un objetivo: consecucin de determinados resultados. Los objetivos son los
que impulsan los proyectos, ya que la planificacin y el desarrollo se ponen en marcha para alcanzarlos.
Implican acometer coordinadamente un conjunto de actividades interrelacionadas: un

proyecto es un sistema, por lo que es bueno que el manager de proyecto utilice conceptos de la Teora de Sistemas y alguna metodologa de anlisis de sistemas.
Duracin limitada: 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 de finalizacin bien definida, se debe tener en claro de que las responsabilidades del equipo de proyecto se extienden en muchos casos ms all de la entrega del producto.
Todas son, hasta cierto punto, nicas y no recurrentes: esta singularidad varia
considerablemente de un proyecto a otro. Por lo tanto la experiencia pasada brinda poca orientacin precisa acerca de lo que se puede esperar, esto agrega riesgo e incertidumbre a los proyectos.
REFLEXIN: "Nopreguntesqupuedehacer portielequipo.Preguntaqu puedeshacertporl" MANUAL TCNICO PMI - IT Cristian Bailey Consultor IT Pg. 4 de 200
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 de proyecto est dirigido a llevar a cabo un proyecto lo ms eficazmente posible, teniendo en cuenta las limitaciones detiempo,dinero(yrecursosengeneral)yespecificaciones. Para hacerles frente a la triple limitacin han surgido diferentes herramientas: TIEMPO: DINERO: ESPECIFICACIONES: Se establecen plazos y se trabaja con horarios y agendas. Se cuenta para ello con Herramientas de Planificacin. Se maneja a travs de Presupuestos: estimaciones de costo, control y seguimiento. Existen varias herramientas para manejar los recursos materiales y humanos. Describen como debe ser el producto del proyecto y que debe hacer. Son notoriamente difciles de establecer y controlar. Esta es la limitacin ms difcil de manejar.
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 4 grandes fases: Concepcindelproyecto,Planificacin,ImplementacinyFinalizacin.
Nivel de Recursos en ($)
Proyecto de investigacin de mercado
Tiempo
Nivel de Recursos en ($)
Proyecto de investigacin cientfica
Tiempo
Independientemente de cmo se considere el ciclo de vida el punto ms importante es que a lo largo de su vida todo proyecto es dinmico, es un emprendimiento en continua evolucin. REFLEXIN: "Demostrartuliderazgosignificaquecuandosurgenlosproblemaslos enfrentasdeunamaneramadura,racionalysincera,pormuymolestoquete
Pg. 5 de 200
DINMICA DEL CICLO DE VIDA DEL PROYECTO.
Se divide fundamentalmente en seis funciones, que se cumplen durante el curso del proyecto:
Necesidades
Seleccin del Proyecto Planificacin del Proyecto
Implementacin del proyecto
Control del Proyecto
Evaluacin
Evaluacin
Evaluacin
Terminacin
A).- Seleccin del Proyecto:

Los proyectos surgen de necesidades que debe ser satisfechas y debido a la existencia de recursos escasos se debe decidir y seleccionar en base a las necesidades, el coste que suponen, los recursos y la importancia relativa de 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. Una decisin siempre debe estar basada en el anlisis de un sinnmero de antecedentes, con la aplicacin de una metodologa 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 del CEO, con el contexto y los anlisis: tcnico, econmico financiero, socioeconmico, ambiental, etc... Estos son los criterios 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 necesariamente deben funcionar correctamente para que el proyecto, el proceso, la empresa sean exitosos.
Pg. 6 de 200
REFLEXIN: "El mayor de los peligros para la mayora de nosotros, no es que nuestroobjetivoseademasiadoalto y no lo alcancemos, sino que sea demasiadobajoylologremos"
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 se los 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 flujos esperados durante el desarrollo del proyecto y hasta una cantidad de aos a definir o de funcionamiento en rgimen de la solucin implantada. 2. PERIODO DE RECUPERACIN, mide en que tiempo el proyecto devuelve su inversin inicial. No considera 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 sobre la 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 proyecto despus de amortizacin e impuestos, por el valor medio de la inversin y se lo compara con el rendimiento contable de la entidad. 5. COSTO ACTUAL NETO, surge de descontar a una tasa o costo de oportunidad del capital los flujos de costos 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 es lograr 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 las tareas y su interdependencia, se debe lograr tambin el compromiso de sectores que participaran en su ejecucinadministracin y se identifican los responsables. Luego se debe planificar, revisar y ajustar a nivel de detalle la ingeniera 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 asignacin de recursos, de responsabilidad, etc. A medida que el proyecto avanza, el plan puede sufrir continuas modificaciones, que reflejaran las circunstancias imprevistas que se presente y las respuestas que se les de, por eso se dicen que los planes son suposiciones.
C).- Implementacin:
MANUAL TCNICO PMI - IT 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 la puesta en marcha del proyecto, por ejemplo: Aplicativos integrados. Administradores de bases de datos. Redes, tipos, velocidad de transferencia. Tipos de monitores, equipos de multimedia. Cristian Bailey Consultor IT Pg. 7 de 200
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 la implementacin.
D).- Control:
A medida que se implementa el proyecto, sus administradores controlan continuamente el progreso, examinan lo que se hizo hasta ese momento, recolectan y analizan de datos, estudian el plan y determinan si hay discrepancias importantes 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 mencionado anteriormente. Las variaciones siempre existirn, los niveles estimados como aceptables son determinados al iniciar el 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 para este trabajo.
GESTIN DE PROYECTOS:
Se define como la aplicacin de conocimientos, herramientas, y tcnicas a las actividades que conforman el proyecto, esto se refiere a la parte de documentar los procesos y generar alertas tempranas en base a la evolucin de 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 el proyecto) del panorama generalizado, realizadas por un individuo o grupo que no trabaja directamente en el proyecto (para mantener la objetividad). En esta etapa se evalan los resultados logrados, versus los esperados, se evalan tambin los desempeos y se impulsan las mejoras continuas. La evaluacin es un examen objetivo y peridico para determinar el estado de un proyecto 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.
Pg. 8 de 200
REFLEXIN: "No hay nadie menos afortunado queelhombre aquienlaadversidad olvida, pues no tiene oportunidad deponerseaprueba"
Evaluacin Intermedia: Estamos alcanzando nuestros objetivos NO Los Objetivos bsicos an son vlidos? NO SI SI
Los Objetivos bsicos an son vlidos?
NO
SI Continuar con el proyecto
Adaptar el proyecto para alcanzar los objetivos
Queremos cambiar nuestros objetivos NO SI
Queremos cambiar nuestros objetivos NO SI

Cambiar los objetivos y continuar con el proyecto
Cambiar los objetivos y continuar con el proyecto Terminar el Proyecto
Terminar el Proyecto
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, las responsabilidades del manager continan a travs de diversas tareas finales, la reasignacin de tareas a los miembros del equipo del proyecto, determinar si el proyecto satisface los requerimientos de los usuarios y la elaboracin de informes finales, recopilacin de documentacin, etc. Es necesario que estas tareas se lleven a cabo para 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 es muy importante, a pesar de esto no esta incluido en el ciclo vital del proyecto, puesto que los proyectos tienen un principio 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 organizacin Impulsar en toda la organizacin la bsqueda de mejores soluciones que hagan obsoletas aun los proyectos 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 Cristian Bailey Consultor IT Pg. 9 de 200 MANUAL TCNICO PMI - IT
presenta coincidentemente la funcin de planificacin del proyecto, mientras que en la fase de implementacin se encuentra en forma conjunta la fase de implementacin del proyecto y de control del mismo. En la fase de Finalizacin es posible observar la fase de Evaluacin y la Terminacin del proyecto.
EL MANAGEMENT DE PROYECTO DE TECNOLOGA INFORMTICA Y SISTEMAS DE INFORMACIN

Tradicionalmente fue utilizado en la industria de la construccin, la arquitectura y la ingeniera, en las ltimas dcadas, 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, fluido y 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 enfrentarn grandes problemas. Buena parte de la tarea de los managers de proyecto consiste en minimizar las consecuencias negativas de esos problemas inesperados. Las tres fuentes principales de fracaso de los proyectos son:
FACTORES ORGANIZACIONALES:
1. 2. Los problemas organizacionales son la norma en todo tipo de organizacin, la naturaleza misma del Management de proyecto hace que surjan. Una caracterstica comn es el divorcio entre responsabilidad y autoridad, al manager de proyecto no se les da control directo sobre todo el proceso, tiene poca autoridad directa para imponer su voluntad sobre los individuos que trabajan en el proyecto. Si el proyecto tiene xito, se deber a la habilidad del manager para influir sobre los principales agentes y coordinar su trabajo, y tambin de la disposicin de esos agentes para cooperar con ella.
3.
Mala identificacin de las necesidades del cliente y especificacin incorrecta de los requerimientos:
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 y dentro del presupuesto. Esto se puede deber a que el producto refleja la visin de los altos puestos respecto de las necesidades del usuario, o refleja la opinin del diseador porque los clientes no saben bien lo que necesitan. Muchas veces los problemas surgen despus de finalizado o a mitad del desarrollo, y ello ocasiona aumento de costos y plazos. Para evitarlos, los managers cuentan con tcnicas simples para definir y controlar con eficacia las necesidades y los requerimientos. MANUAL TCNICO PMI - IT
2. 3.
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 ser necesario introducir ajustes necesarios para mantener el curso del proyecto. Son actividades concretas y prcticas, se aplican a la distribucin del tiempo, de los recursos materiales y humanos, son susceptibles de medicin y existen herramientas para trabajar en ambas reas.
2.
Pg. 10 de 200
A pesar de esto, es comn que se los realice incorrectamente, sin embargo pueden transmitirse buenas prcticas de 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 correctas

La direccin de proyectos tiene que ver con el liderazgo y todo lo que implica, al igual que los conceptos de emprendimiento, o sea la capacidad de crear acciones y el de "poltica", ya que juega un papel muy importante la capacidad de influir en los dems para que sigan sus instrucciones.
ASPECTOS A TENER EN CUENTA PARA EL DESARROLLO DE PROYECTOS

OPERAR DENTRO DE LAS REALIDADES DE LA VIDA ORGANIZACIONAL
No 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 nulo control sobre las personas y cosas que son importantes para el fracaso o xito del proyecto. Por lo general, su personal es prestado y los recursos materiales necesarios oficinas, instrumentos cientficos, herramientas - deben ser 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 trabajar especialistas y no es raro que cambien continuamente a medida que avanza el ciclo de vida del proyecto.
Fortalecer la Autoridad:
Este aspecto es de mucha utilidad puesto que la autoridad es la capacidad para hacer que la gente nos tome en serio y cumpla nuestras rdenes. Para lograrlo hay que crear y fortalecer la base de autoridad, entre ellas podemos encontrar: Autoridad formal: le es conferida con la designacin para dirigir el proyecto e indica un respaldo desde arriba. La calidad de autoridad formal que posea depender de si es una vaga sensacin o un respaldo pblico y fuerte. En general, la escasa autoridad formal que tiene no es suficiente para contrarrestar otras fuerzas que le impiden ejercer el control directo sobre RRHH y materiales.
su autoridad se basa en la comprensin de la importancia de llevar bien los papeles, fijar plazos aparentemente arbitrarios para la presentacin de informes sobre la marcha del proyecto y conocer todos los detalles de la direccin de los trmites dentro de la organizacin.
Autoridad burocrtica:
Pg. 11 de 200
Autoridad econmica: deriva de la autonoma presupuestaria y un buen uso de ella. Es til especialmente con los agentes externos que dependen del pago de bienes y servicios que entregan. Es muy comn, sin embargo que se tenga poco control sobre el presupuesto, aunque puede ejercer autoridad econmica a travs del control de los recursos no monetarios, por ejemplo el tiempo de la gente, la asignacin de actividades y de prioridades y preferencias.
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 les
obedezca, 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 de lograr que los dems los escuchen y cumplan sus rdenes por medio de la fuerza de su personalidad. El manager carismtico est convencido de su misin, tiene sentido del humor, tiene empata hacia las necesidades del equipo, es entusiasta y seguro de s. Es un lder.
La importancia de la autoridad es que sta le otorga al profesional cierta influencia sobre los otros agentesdelproyecto.Sinesainfluenciaelldernopodrcontrolarelproyecto.
EL AMBIENTE COMPLETO DEL PROYECTO

La 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 una tarea compleja para llevar adelante el proyecto: un problema con cualquiera de los agentes puede hacerlo descarrilar. Los directores de proyecto tienen que tratar no slo con el ambiente de la organizacin, sino tambin con su ambiente interno. Tenemos entonces un ambiente de Management complejo. Las relaciones con los diferentes actores son tambin importantes, porque los problemas que surjan con cualquiera de ellos pueden poner en peligro la totalidad del proyecto. Pero tambin, la buena relacin con cualquiera de ellos ayudar enormemente al lder del proyecto. 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 que en proyectos de mayor visibilidad por su grado de significacin, los altos ejecutivos se sientan mas interesados en participar. EL JEFE: actualmente este concepto est siendo reevaluado. A medida que las organizaciones se apartan de las estructuras tradicionales y se vuelven hacia estructuras centradas en el trabajo en equipo, ya no queda tan en claro quin reporta a quin. La realidad es que los jefes todava existen y es preciso interactuar con ellos. Lo ms corriente es que sea el jefe quien decida que tarea desempearemos y quien trabajar con nosotros en nuestro proyecto. LOS COLEGAS: los otros gerentes de proyecto y la mayora de nuestros pares pueden ser amigos, enemigos o un poco de cada cosa. Pueden ser amigos porque son recursos tiles y pueden brindarnos importante informacin 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 asigna a un proyecto con dedicacin exclusiva y permanente. Por esta causa las actividades orientadas hacia el proyecto suelen organizarse con una estructura de matriz. Detrs del Management de matriz actan dos fuerzas impulsoras. Una es la eficiencia del empleo de los recursos, la otra es que permite darles a los problemas soluciones transfuncionales. Los problemas complejos requieren el aporte de una vasta gama de agentes o actores. LOS MANAGERS QUE CONTROLAN LOS RECURSOS INTERNOS: si los directores de proyectos tienen buena relacin con esta categora de actores, tal vez puedan conseguir el mejor personal y equipamiento para su 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. Pg. 12 de 200

LOS CLIENTES INTERNOS: son individuos pertenecientes a la organizacin y tienen determinadas necesidades, que sern satisfechas por medio de un proyecto de ejecucin interna. LOS CLIENTES EXTERNOS: Son individuos u organizaciones del medio. Los proyectos satisfacen sus necesidades 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 la necesidad de un cliente externo a travs de un contrato. En tal caso los managers tienen una idea clara de quines son sus clientes y deben tener una buena comunicacin con ellos, para estar seguros de que quedarn satisfechos. EL GOBIERNO: los que trabajan en campos fuertemente regulados deben conocer las reglamentaciones que influyen sobre sus proyectos. En estos casos el manager de proyecto no slo enfrenta los problemas comunes a 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 recursos necesarios para acometer la realizacin de los proyectos que concibe. Los directores de proyecto que trabajan con subcontratistas deben controlar de cerca su desempeo, ya que el xito del proyecto depende en parte de ellos. LOS PROVEEDORES: muchos proyectos dependen en gran medida de productos que deben ser aportados por proveedores externos a la organizacin. Para hacer un buen Management de proyectos es necesario contar con proveedores confiables.
LA POLTICA DE LOS PROYECTOS

La poltica es el arte de la influencia. Los managers de los proyectos se parecen a los polticos. No son de por s poderosos, 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. Necesitan tambin 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 trata de 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 ms fuertes que las laborales. Al ocuparnos de los objetivos, obvios e implcitos, debemos poner especial atencin en los objetivos de los actores que tiene el poder, para determinar de qu forma debemos influir sobre ellos para que nos ayuden a concretar los objetivos del proyecto. EVALUAR LAS PROPIAS CAPACIDADES: los directores de proyecto deben tener una idea clara de sus fuerzas 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. DEFINIR EL PROBLEMA: 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 supuestos bsicos que sustentan el mtodo de definicin del problema. DESARROLLAR SOLUCIONES: es muy frecuente que el equipo del proyecto empiece por aqu. Empiezan por ofrecer soluciones antes de haber entendido cabalmente el problema. Si embargo, si pueden ejercer un verdadero autocontrol y se abstienen de ofrecer soluciones prematuras las soluciones que elaboren tendrn el importante mrito de ser realistas y pertinentes al verdadero problema. perfeccionadas. Este sexto paso, se concentrar en dar los toques finales a las soluciones realistas elaboradas inteligentemente. MANUAL TCNICO PMI - IT
3.
4.
5.
6. VERIFICAR Y PERFECCIONAR LAS SOLUCIONES: las soluciones deben ser continuamente verificadas y
Pg. 13 de 200
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 emprendimiento dependern 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 de empleados con responsabilidad, organizaciones planas y direccin de equipo. Actualmente se sostiene que la funcin clave de los gerentes es apoyar, es decir, crear un ambiente que les permita a los empleados trabajar lo mejor posible. La tarea del manager es crear un ambiente en el que el equipo transfuncional pueda llegar a un consenso 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 y conflictos. La toma de decisiones se distribuye a lo largo del proceso de realizacin de un proyecto cuando ste demasiado complejo para ser manejado en un estilo rgidamente jerrquico, con una cadena de mandos claramente establecida. 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. Ello quiere decir que se le da al equipo de trabajo amplia libertad de accin para tomas decisiones, dado que las decisiones individuales no afectan el presupuesto, el organigrama o la utilizacin de los recursos ni pueden producir problemas polticos. Slo cuando es evidente que las cosas se le estn yendo de las manos, el director del proyecto interviene directamente en la toma de decisiones. Cristian Bailey Consultor IT Pg. 14 de 200
Tendr una varianza de organigrama inaceptable?
S No
Tendr una varianza de presupuesto inaceptable?
S No GERENTE DE PROYECTO S
Me apartar demasiado de las especificaciones?
No
La cuestin que estoy apoyando es polticamente sensible?
No
Toma de decisin
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: una organizacional y la otra, psicosocial.
La perspectiva organizacional.
La estructura de matriz que impera en muchas organizaciones no favorece el compromiso personal con los proyectos. El sistema de remuneracin de la estructura de matriz tampoco contribuye e generar incentivos para que una persona dedique largas horas a su trabajo. En estas circunstancias organizacionales no es sorprendente encontrarse con bastante reticencia de parte del personal del proyecto para comprometerse con el proyecto y trabajar horas extras. Adems muchas veces participan en varios proyectos al mismo tiempo, lo que debilita an su compromiso. MANUAL TCNICO PMI - IT
La perspectiva psicosocial.
Se trata de algo muy simple pero casi siempre ignorado: las personas que trabajan en proyectos son multidimensionales. Si los directores de proyecto tratan a la gente como si el trabajo fuese lo nico que les importara, tendrn que sufrir dos consecuencias: la primera, que estarn constantemente descontentos con su equipo 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.
Pg. 15 de 200
Pero tanto esfuerzo est, en general, mal orientado. En primer lugar, si el personal del proyecto no tiene un fuerte compromiso con l no lograrn que trabajen ms. Y, segundo, es tpico que el equipo de proyectos no sea demasiado productivo, o sea, que no se trata de hacer que las personas trabajen ms duro sino de lograr que trabajen inteligentemente. Nuestros esfuerzos deben estar dirigidos a incrementar la productividad. Para trabajar con inteligencia debemos seguir ciertas reglas. Hacer las cosas bien la primera vez: los gerentes de proyecto deben esforzarse al mximo para lograr que sus colaboradores hagan las cosas bien la primera vez. Cuando vemos que se estn haciendo las cosas ms de una vez antes de llegar a la manera correcta hay una alta probabilidad que sea por un problema comunicacional. Fijar objetivos realistas: planifique de manera realista. No se ponga en situacin de depender de gente que no es con la que usted cuenta. La principal desventaja de esta solucin es que los gerentes de proyecto suelen tener poca participacin en el proceso de planificacin. Una vez iniciadas las conversaciones, si el futuro director 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 contamos con 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 entender por 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 de los 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 del comportamiento humano. Esas cuatro escalas dan lugar a diecisis casilleros donde es posible ubicar a una persona. Si conocemos el tipo psicolgico de alguien, podemos inferir rpidamente cmo se comportar en determinada circunstancia. Esa informacin es til para los gerentes de proyecto, que deben tratar constantemente con muchas personas diferentes en toda clase de circunstancias. LA DIMENSIN EXTROVERSININTROVERSIN: segn el esquema Myers-Briggs, un extrovertido es alguien orientado hacia el mundo exterior, el mundo de las personas y las cosas; y un introvertido es alguien orientado hacia el mundo interior, el de los conceptos y las ideas. Los extrovertidos suelen ser prcticos, les gusta hacer varias cosas al mismo tiempo. Los introvertidos son propensos a vivir sobre todo en su mente. Piensan con ms profundidad que los extrovertidos. LA DIMENSIN SENSITIVIDADINTUICIN: 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 los hechos en s mismos, sino las posibilidades que sugieren. Son imaginativos, se interesan ms por cmo podran ser las cosas que por cmo son realmente. LA DIMENSIN RACIONALIDADAFECTIVIDAD: las personas perciben la realidad y despus emiten juicios acerca de su significado. Algunos lo hacen a travs de un proceso fro y desligado: son los racionales. Estos individuos se sientes ms cmodos en contacto con las cosas y los conceptos que con la gente. Tambin hay personas que basan sus juicios en consideraciones ms subjetivas, en respuestas que salen del corazn. Se sienten ms cmodas en contacto con la gente que con las cosas. Son los afectivos.
Pg. 16 de 200
LA DIMENSIN JUICIOPERCEPCIN: en esta dimensin se examina hasta que punto las personas se sienten obligadas a sacar conclusiones en el mundo circundante. Algunos individuos formulan un juicio inmediatamente. Siempre toman una decisin con rapidez; jams la postergan. Se sienten cmodos dentro del orden y la planificacin. El aspecto negativo es que suelen ser rgidos y estrechos de miras y corren el riesgo de 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 ms informacin. Estas personas son flexibles y abiertas. Corren el riesgo de ser desorganizadas y de caer en la trampa de 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 as manejar 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 PROYECTO
Las responsabilidades principales del gerente de proyecto son las siguientes: DESARROLLARELEQUIPO:el know-how del director de proyecto se transmite informalmente. Los gerentes aprenden 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 as se est desarrollando el equipo. ACTUAR COMO INTERMEDIARIO ENTRE LOS DIRECTIVOS Y EL EQUIPO: los gerentes de proyecto tiene por encima a los altos niveles del Management y por debajo a los empleados. Por un lado forman parte del plantel ejecutivo. Son el canal a travs del cual fluye la informacin desde los directivos hacia los empleados. 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. Suelen ser tiles a sus organizaciones transmitiendo lo que han aprendido a sus pares, a los directivos y a los empleados. Estos conocimientos se transmiten generalmente de manera informal durante reuniones informales o 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 ni tampoco les interesa la realimentacin proveniente del equipo.
EL LAISSEZFAIRE: LOS GERENTES PERMISIVOS: nos encontramos con escaso flujo de informacin o con un flujo de informacin aleatorio, que no se canaliza adecuadamente.
Pg. 17 de 200
El estilo gerencial autocrtico tiene sus pros y sus contras. Entre las ventajas podemos decir que el mtodo autocrtico es adecuado para los proyectos de rutina y de bajo riesgo, en los que el equipo se limita a llevar adelante el plan como fue establecido. Es eficaz cuando es preciso tomar decisiones rpidamente. Una desventaja es que el enfoque autocrtico lleva a la desmoralizacin del equipo, ya que los colaboradores no pueden hacer ninguna contribucin importante al proceso de toma de decisiones. Puede llevar a tomar decisiones errneas, ya que el jefe no recibe suficiente informacin desde el exterior.
En un sistema permisivo, el equipo del proyecto debe ser capaz de realimentar a los managers; pero lamentablemente 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 la creatividad y son reacios a imponer sus propios puntos de vista. Si examinamos las desventajas de este enfoque veremos que puede llevar a la desorganizacin por falta de direccin. Otra importante desventaja es que resulta simplemente desastroso cuando es preciso tomar decisiones rpidas. LOS GERENTES DEMOCRTICOS: antes de tomar decisiones, los gerentes democrticos tratan activamente de recibir informacin originada en el equipo. El mtodo democrtico facilita la toma de buenas decisiones, ya que refleja un amplio espectro de puntos de vista. Incrementa el compromiso del equipo de implementar las decisiones ya que el conjunto de sus miembros particip en el proceso decisorio. Una de las desventajas, es algo que los cientficos polticos llaman la tirana de la mayora. Esto se produce cuando en un sistema democrtico siempre se impone determinada mayora, en desmedro de lo que pasa a ser una perpeta minora. La segunda desventaja se pone en evidencia cuando se confeccionan encuestas con los votantes equivocados y, en consecuencia, se toman decisiones sobre la base de una informacin incorrecta. Una tercera 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 ciento por 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 secreto consiste en saber qu estilo aplicar segn las circunstancias. Esa decisin depende, en gran medida, del sentido comn 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 juntas para 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 y slo participan brevemente del trabajo en conjunto. Trabajan en una parte del proyecto y, cuando terminan, pasan a otro. Debido a esto, suelen no sentirse como parte de un equipo. No pueden desarrollar el espritu de equipo, es decir el compromiso con el proyecto. Una de las tareas ms importantes de los gerentes de proyectos consiste en desarrollar en su plantel cierto sentido de 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. En cuanto al equipo mal estructurado, es una frmula segura para fracasar.
Pg. 18 de 200
LA EFICIENCIA DEL EQUIPO.
Definimos a la eficiencia del equipo como la fraccin de desempeo potencial del equipo que se logra realmente. No nos preocupamos por medir con exactitud la eficiencia del equipo sino por alcanzarla. Podemos decir que un equipo de proyecto es ineficiente porque su diseo bsico causa ineficiencia o porque la friccin organizacional impide que opere con la suavidad que podra operar. Las principales fuentes estructurales de ineficiencia de un equipo de proyecto son: FRICCIONES BASADAS EN LA MATRIZ: en un proyecto de estructura de matriz la falta de continuidad del plantel es siempre causa de ineficiencia. La friccin organizacional es alta porque la gente pasa una importante parte de su tiempo de trabajo revisando lo que han hecho otros. Si consideramos este hecho con la falta de compromiso caracterstica de los proyectos con personal de rotacin frecuente, veremos que la ineficiencia ser baja. Otra importante fuente de friccin en un proyecto de matriz es que el manager carece de control directo sobre el plantel y sobre los recursos materiales. MALA COMUNICACIN: examinaremos ahora tres de las diversas clases de friccin basadas en la comunicacin. 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 recibir mensajes, la eficiencia del equipo empieza a disminuir. ARTERIOSCLEROSIS DE LA INFORMACIN: se produce cuando los canales de comunicacin estn tan obstruidos que la informacin importante apenas si puede circular. La obstruccin es consecuencia de la exigencia de que la informacin sea procesada de manera burocrtica. Tambin pude ser causada por grandes cantidades de informacin intil que circula por los canales y bloquea el flujo de mensajes importantes. Frente a esto vemos que el trabajo en equipo se ve perjudicado. MENSAJES DISTORSIONADOS: en los proyectos, las instrucciones que llegan distorsionadas pueden lograr que el equipo realice mal su trabajo. Si ese trabajo tiene que hacerse nuevamente o si causa problemas en otras reas, la eficiencia del equipo diminuye. La comunicacin entre los clientes del producto y el equipo es tambin muy importante. Si las necesidades de los clientes son mal transmitidas al equipo, el producto final ser rechazado. que 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 que sean eficaces integradores del sistema, aumentarn drsticamente la eficiencia de su equipo de
1.
2.
3.
MALA INTEGRACIN: los directores del proyecto deben integrar las piezas, reunir todos los elementos para
trabajo.
COMO ESTRUCTURAR LOS EQUIPOS.

Para estructurar equipos de proyecto de modo de incrementar la eficiencia del trabajo, debemos evitar las estructuras 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 preciso tener 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 un equipo de proyecto de modo que refleje fielmente la estructura fsica del producto, lo que se est produciendo, el equipo y el producto sern mutuamente isomrficos.
Pg. 19 de 200
Con un proyecto as estructurado se corre el riesgo de que las partes no encajen bien, ya que se las desarrolla por separado. 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 a diversas tareas. Por lo tanto, el conocimiento es usado donde conviene hacerlo. Con este mtodo, los gerentes de proyecto se enfrentan al clsico dilema del Management de matriz: tienen un alto nivel de responsabilidad pero carece del correspondiente nivel de autoridad. Algunas de las deficiencias de la estructuracin de los equipos por especialidad son: la responsabilidad es muy difusa 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 desplaza notablemente desde el gerente de proyecto hacia los miembros del equipo. Los conocimientos se aplican donde es conveniente hacerlo.
Si observamos un producto desarrollado por un equipo sin egocentrismo, o sea el resultado de un trabajo de verdadera colaboracin, no podremos discernir quin produjo qu parte. La estructura del equipo no egocntrico fomenta altos niveles de interaccin y comunicacin entre los colaboradores. Si la comunicacin es buena y si los miembros del equipo trabajan juntos hacia un objetivo comn, los problemas de integracin de sistemas sern pocos. Una de las crticas ms frecuentes es que el equipo no egocntrico no funciona porque cada persona tiene su propio ego. 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 son numerosos y ello produce burocracia y sus correspondientes ineficiencias. Segundo, los equipos no egocntricos requieren que los colaboradores tengan continuidad: en ese aspecto se parecen mucho a un equipo deportivo. Tercero, los equipos no egocntricos pueden funcionar bien en proyectos de vanguardia en los que al principio el producto final est definido vagamente. Los equipos no egocntricos suelen ser eficaces en proyectos en los que sus miembros, sumamente creativos, se resisten a aceptar un liderazgo fuerte porque va en contra de sus principios y porque restringe la creatividad. El concepto de equipo no egocntrico es particularmente interesante hoy en da,porquemuchosdesusprincipiosbsicosrevivenenelconceptodeequiposautogerenciados.
LAESTRUCTURADELEQUIPOSINEGOCENTRISMO.
LAESTRUCTURADELEQUIPOQUIRRGICO.
El mtodo del equipo quirrgico tiene una ventaja importante: que elimina el problema de la integracin de los sistemas. Como el producto del proyecto fluye directamente de la mente de un solo individuo, es muy probable que las partes encajen perfectamente. El mtodo quirrgico tiene una desventaja importante: que para desempear el papel de cirujano requiere un individuo 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, Cristian Bailey Consultor IT Pg. 20 de 200
En la direccin de proyecto se le da a un individuo la responsabilidad total de llevar adelante el cuerpo principal del trabajo de proyecto y se lo resguarda de presiones administrativas. En cuanto a la estructuracin de equipos, el mtodo quirrgico es diametralmente opuesto al no egocntrico. En el primero, toda la atencin se concentra en un solo individuo y en su capacidad. En el segundo, lo que cuenta en el trabajo general del grupo.
pero sobre todo en lo concerniente a las cuestiones tcnicas. El administrador del proyecto tambin es jefe, porque est 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 y controlar 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 los que implican gran cantidad de redaccin de textos. Tambin puede ser usado en proyectos grandes si se le da esta estructura a cada uno de los mdulos. La estructura del equipo tiene enorme influencia sobre su desarrollo y desenlace. No hay una sola estructura perfecta 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 que gran 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 identidad entre 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 tangibles sus equipos. Algunos recursos para esto son: organizar reuniones, conseguir un espacio fsico para el trabajo grupal, darle un nombre al equipo. Usar bien las reuniones: el propsito ms evidente de las reuniones de equipo es comunicar la informacin. Una funcin menos obvia consiste en establecer una identidad de equipo concreta. Al iniciarse un proyecto se organiza la reunin de lanzamiento que hace tangible al grupo. Si es posible, debe estar presente un ejecutivo de alto nivel, para demostrar claramente el compromiso de los directivos con el proyecto. Otra reunin importante es la de revisin del estado del trabajo. Se trata de reuniones peridicas en 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 en un espacio comn. Hay que establecer un cuartel general puesto que sirve como seal tangible de la existencia del equipo. Aun cuando se encuentre apartado del mbito de sus actividades cotidianas, los colaboradores asociarn al equipo con el cuartel general. Darle nombre al equipo: otro recurso para dar vida concreta al equipo es bautizarlo. Muchas veces se crea tambin un logotipo.
2.
Pg. 21 de 200
CREAR UN SISTEMA DE RECOMPENSAS: sin incentivos, es difcil motivar a los colaboradores de un proyecto. Como los miembros del equipo de proyectos no participan del sistema de recompensas y castigos de la 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, oficina confortable, etc. Nuevo equipamiento: cada vez que se reciba nuevo equipamiento, las mejores piezas se distribuirn entre los colaboradores ms destacados, como seal de reconocimiento por sus esfuerzos (este recurso es especialmente eficaz con personal tcnico).
Recomendacin para la asignacin de bonificaciones: los mejores empleados reciben bonificaciones en dinero efectivo. Desde luego, los directores de proyecto deben apoyarse en esta posibilidad para motivar a su gente.
3.
DAR UN TOQUE PERSONAL AL EQUIPO: el tercer recurso para construir un sentimiento de identidad de equipo 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 las siguientes 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 otras caractersticas.
ASEGURARSE DE QUE EL PROYECTO SE BASE SOBRE UNA NECESIDAD CLARA

EVOLUCIN DE LAS NECESIDADES.
Las necesidades son la fuerza motriz fundamental que impulsa los proyectos. El surgimiento de una necesidad desencadena el proceso del proyecto. Si al comienzo no comprendemos totalmente una necesidad y sus consecuencias, si la formulamos incorrectamente, o si por error abordamos una necesidad equivocada, habremos dado 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 las necesidades. Esto es seguido a su vez por una fase de formulacin de las necesidades. Una vez expresadas, las necesidades pueden servir de base para establecer los requerimientos funcionales (descripcin detallada de lo que un proyecto tendra que hacer para satisfacer las necesidades que se han formulado). A partir de estos requerimientos, 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, debemos enfrentar constantemente la aparicin de nuevas necesidades. Las necesidades pueden surgir desde adentro o desde afuera de una organizacin. Las necesidades internas por lo general se relacionan con la mejora del desempeo organizacional.
2.
RECONOCIMIENTO DE LAS NECESIDADES.
Sin embrago, no basta con que slo surjan necesidades. Esas necesidades deben ser reconocidas. Si no, no se emprender accin alguna para satisfacerlas. No es fcil detectar las necesidades nuevas. El reconocimiento de las necesidades 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 las que surgirn. Esto se hace en base al plan estratgico de la organizacin, y el plan estratgico de TI.
3.
FORMULACIN DE LAS NECESIDADES

Una vez reconocida la necesidad, es preciso formularla claramente. Esta formulacin implica un examen profundo de la necesidad reconocida. Por medio de ese examen nuestra comprensin de la necesidad cambiar. La formulacin de las necesidades tiene, adems, un costado prctico: sirve de base para el desarrollo de los requerimientos funcionales. En la prctica, las necesidades pueden ser formuladas de muchas maneras diferentes. Uno de los mtodos posibles para 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 Pg. 22 de 200
vaga de la necesidad. Para ello existen plantillas de captura de informacin o definicin de procesos que permiten establecer las necesidades y as poder documentarla y evaluarla en base a la ptica del cliente, por ejemplo la metodologa 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 la necesidad 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 en condiciones 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 necesidad antes el usuario o cliente interno que realiza el requerimiento de la necesidad para que el determine si entendemos su 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 ciclo vital de las necesidades y los requerimientos, es muy comn que los expertos modifiquen las necesidades para que los 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 realmente las 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 plan de proyecto. Hacemos esto formulando las necesidades como requerimientos funcionales (describen caractersticas del producto en lenguaje corriente, de modo que cualquier persona sin conocimientos tcnicos pueda comprenderlas). Los requerimientos tcnicos surgen de los requerimientos funcionales (se escriben para el equipo tcnico). La especificacin de los requerimientos es una de las tareas ms difciles que deben realizar los planificadores y los gerentes de proyecto. Los requisitos inadecuadamente especificados producen siempre el fracaso o el mal desempeo 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 deduce que el proceso de definicin de las necesidades puede marchar mal por diversos motivos y en diferentes formas. Examinaremos tres categoras amplias de problemas.
1.
La causa fundamental de la dificultad para definir las necesidades es que esas necesidades son inherentemente vagas. 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 y nosotros nos esforzamos por formularlas con precisin, el ambiente no se queda quieto, sino que sigue cambiando. 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 esa partida sea retirada. Cambio de tecnologa: cada vez que se introduce en el mercado una tecnologa nueva, esa tecnologa estimula a la gente y la induce a replantearse sus necesidades. Modificacin del ambiente comercial.
CMOENCARARLASNECESIDADESNECESARIAMENTEVAGAS.
Pg. 23 de 200
Teniendo en cuenta la naturaleza dinmica de las necesidades, es una buena idea crear planes de proyectos flexibles. Hay algo ms que los planificadores y los gerentes de proyecto pueden hacer: prever los cambios en las necesidades por medio de la prediccin. Al formular una necesidad, el gerente de proyecto no debe definirla en funcin 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 posible satisfacerlas de modo eficaz, al menos mientras se las conciba de esa forma. Las implicancias de todo esto para los planificadores de proyecto son clara: si los gerentes basan sus planes slo en las formulaciones de las necesidades del cliente, es casi seguro que no lograrn producir objetos que satisfagan 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 ser una gua para los clientes. Al trabajar en estrecho contacto con clientes, los miembros del equipo de proyecto deben ayudarlos a identificar claramente lo que necesitan
2. IDENTIFICARLASSOLUCIONESPREMATURAMENTE.
La inherente vaguedad de las necesidades es una trampa importante que acecha constantemente a los planificadores 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 anlisis de las necesidades requiere una buena dosis de paciencia y autocontrol. Con frecuencia estamos 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 dejemos abierta 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. Slo despus de haber cumplido con todo este proceso dispondremos de informacin suficiente para considerar con seriedad las soluciones especficas que podran satisfacer nuestras necesidades.
En las primeras etapas del ciclo vital de las necesidades y los requerimientos, debemos tratar de esclarecer quienes son las personas que experimentan esas necesidades. Si no, existen grandes posibilidades de que tratemos de satisfacer las necesidades de personas que no son las necesitadas. Hay dos inconvenientes o engaos posibles: hay muchos clientes y nosotros encaramos la resolucin de las necesidades del sector equivocado de clientes. Y el segundo malentendido es que nuestros valores personales tian nuestra interpretacin de las necesidades del cliente, y terminamos encarando la satisfaccin de nuestras necesidades. CMODISTINGUIRLASNECESIDADESDELOSDIFERENTESCLIENTES. Siempre hay muchos clientes involucrados, y sus necesidades por lo general no se superponen. Un planificador de proyectos debe distinguir las diversas necesidades, determinar cules son las ms importantes y construir un nuevo conjunto 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 tornarse compleja. Esto se debe al hecho de que hay ms necesidades. Estas diversas necesidades pueden entrar en conflicto, por lo tanto, es evidente que hay que establecer prioridades. ESTABLECERPRIORIDADES:LAJERARQUADENECESIDADES La jerarqua de necesidades es un diagrama que muestra toda la gama de necesidades para determinado problema y sus relaciones mutuas. Las necesidades que aparecen en un nivel incorporan las necesidades que aparecen en el nivel inferior siguiente. En todos los niveles de la jerarqua es preciso tomar decisiones para establecer prioridades entre las necesidades encontradas en ese nivel. Para elaborar los detalles de una jerarqua de necesidades, es preciso determinar el contexto de la situacin. Al construir una jerarqua, nos vemos obligados a actuar sistemticamente para identificar a los actores relevantes y sus necesidades. Tambin tendremos que tomar decisiones: establecer un orden de importancia. Y, por ltimo, si recurrimos a un equipo bien elegido de anlisis transfuncional de las necesidades para que construya la jerarqua Pg. 24 de 200
3. ENCARARLASNECESIDADESDELOSCLIENTESEQUIVOCADOS.
por medio de un proceso de consenso, incrementaremos tambin la posibilidad de que las necesidades formuladas reflejen las verdaderas necesidades de los clientes.
Necesidad Global
Necesidad
Necesidad
Necesidad
Necesidades subsidiarias
Necesidades subsidiarias
Necesidad
Necesidad
Necesidad
DISTORSIONARLASNECESIDADESDELOSCLIENTES. Siempre existe el peligro de que los individuos que analizan las necesidades alteren su formulacin a fin de reflejar sus 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 barato puede 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 las necesidades, no porque no les guste la tecnologa ms avanzada, sino porque la disciplina de la cuenta exigua, las obliga a ser prudentes. FILTRAR SELECTIVAMENTE LAS NECESIDADES DEL CLIENTE: todos vemos el mundo a travs de un filtro que refleja nuestras experiencias, valores y conocimientos. Nuestros filtros tien nuestra percepcin de las cosas. Los problemas empiezan cuando nuestras percepciones se desvan drsticamente de la realidad. En tal situacin nuestra respuesta a los problemas puede tener poca relacin con lo que se necesita para resolverlos. La mejor manera de superar este problema es hacer que el reconocimiento y la formulacin de las necesidades sean aplicados por un grupo transfuncional. As las necesidades sern contempladas desde diversos ngulos. APLICAR AL RECONOCIMIENTO Y LA FORMULACIN DE LAS NECESIDADES EL MTODO LLAMADO PAP SABE LO QUE HACE: por lo 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 la necesidad del cliente en algo concreto y viable. El agente asume una postura paternalista y piensa que sabe lo que es mejor para su cliente, aun cuando ese cliente se resista a aceptar sus sugerencias. En esta situacin, es muy probable, que el proyecto resultante de la formulacin que hagan desemboque en un producto que ser mal interpretado, mal utilizado o simplemente no usado. MANUAL TCNICO PMI - IT
ESPECIFICAR LO QUE EL PROYECTO DEBE LOGRAR.

Los malentendidos y los errores son una presencia constante en la vida cotidiana. Los proyectos tambin estn llenos de malentendidos entre el equipo y los clientes. Con mucha frecuencia lo que el cliente recibe no es lo que pidi o, exactamente, lo que cree que pidi.
Pg. 25 de 200
La esencia misma de una importante fuente de malentendidos en los proyectos es la formulacin incorrecta de los requerimientos del cliente. Los directores del proyecto deben esforzarse por reducir al mnimo posible el riesgo de malentendidos, 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 categoras bsicas: requerimientos funcionales y requerimientos tcnicos. Los requerimientos funcionales describen las caractersticas del producto en lenguaje corriente, no tcnico. Deben ser comprensibles para los clientes. En cuanto 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 encarnacin tangible de las necesidades del cliente. La planificacin del proyecto se reduce a determinar cul es la mejor manera de satisfacer las exigencias de las especificaciones. Y si stas son errneas o estn mal expresadas, el plan ser defectuoso. En segundo lugar, las especificaciones son importantes porque definen las obligaciones que el equipo tiene para con los clientes.
PROBLEMAS CON LOS REQUERIMIENTOS.

Los problemas de especificaciones se producen por diversas causas: las especificaciones son incorrectas, son imprecisas o ambiguas, cambian a medida que se desarrolla el proyecto. Independientemente de la ndole especfica 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 los clientes quedan totalmente insatisfechos. Lo mejor es evitar los problemas antes de que aparezcan, porque una vez que aparecen es difcil resolverlos. Cmo evitarlos? Esforzndose al mximo por formular cuidadosamente las necesidades del cliente y trabajando despus en estrecho contacto con l para elaborar especificaciones funcionales precisas, carentes de toda ambigedad. 1.REQUERIMIENTOSINCORRECTOS. Las necesidades del cliente pueden ser mal interpretadas y mal expresadas, por diversos motivos y de diversas maneras. Las especificaciones funcionales construidas a partir de necesidades mal expresadas no cumplirn su objetivo. El producto final tendr escasa o ninguna relacin con lo que los clientes necesitan y desean. Veamos un resumen 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. El reconocimiento de la dificultad es importante, porque insta a los individuos encargados de formular las necesidades a 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 las necesidades. 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 interpretaciones diversas, es inevitable que haya graves problemas. Las especificaciones se formulan imprecisamente por diversas razones. 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 las especificaciones del producto de un proyecto. Es arriesgado depender slo del lenguaje para describir especificaciones. Para que las especificaciones sean precisas debemos aadir material complementario: dibujos, muestras, mapas, fotografas, datos tcnicos.
IMPRECISIN DELIBERADA EN BENEFICIO DE LA FLEXIBILIDAD.
Pg. 26 de 200
A veces la ambigedad con que se formulan las especificaciones es deliberada y est destinada a preservar 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 muy precisa de los requerimientos limite el trabajo del equipo y desaliente el aprovechamiento de oportunidades inesperadas.
CONSENSO PARA EVITAR CONFLICTOS PERSONALES.
Si las personas involucradas no pueden lograr consenso sobre lo que debe salir de un proyecto, tampoco podrn formular requerimientos precisos. Muchas veces pospondrn decisiones difciles, en espera que el conflicto que las separa se disuelva. En esos casos es probable que las especificaciones formuladas con vaguedad 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 o semi-tangibles. Para disear un proyecto manejamos fundamentalmente abstracciones. Pretender que una 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, los directores y equipos deben tratar de ayudar a los clientes a ver el resultado cuanto antes. Deben valerse de 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. Esa metodologa se llama construccin de prototiposdeaplicacinoconstruccinrpidadeprototipos.
LOS CLIENTES NO SON EXPERTOS

Una de las tareas ms importantes del equipo de trabajo de un proyecto es ensearles a los clientes las caractersticas ms importantes del futuro producto. Por cierto, no es de esperar que los clientes lleguen a saberlo todo. Cunto deben saber? En general, podemos decir que deben saber lo suficiente como para poder hacer un aporte significativo a la formulacin de las necesidades y a la especificacin de los requerimientos. Tambin deben saber lo suficiente para no sorprenderse con el resultado final. Teniendo en cuenta estas condiciones, la cantidad especfica de informacin que deben recibir ser determinada caso por caso.
DESCUIDOS POR PARTE DE LOS AUTORES DE PROYECTOS
La imprecisin de los requerimientos puede deberse a un mero descuido, ms que a prejuicios o mala comprensin del tema. Estas imperfecciones se producen en todos los proyectos, excepto en los ms rutinarios. En cierto modo es inevitable que as sea. Se producen porque todos actuamos segn supuestos tcitos y porque, como no somos omniscientes, carecemos de la imaginacin necesaria para identificar todas las contingencias que podran afectar negativamente nuestro proyecto. Una manera de minimizar estos descuidos consiste en acudir a las personas que realizan las tareas y preguntarles cules son las contingencias que podran surgir en las especificaciones del proyecto. Un buen mtodo de largo plazo para encara estos inconvenientes consiste en compilar poco a poco, proyecto tras 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 fuertes presiones 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 lanzar un costoso proyecto; pero no bien empiezan los trabajos, los responsables cambian de idea. Tratan de reducir el proyecto, para as limitar las perjudiciales consecuencias que imaginan tendran que sufrir si el emprendimiento fuera 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. Todo proyecto innovador corre ese riesgo. Un ejemplo claro de esto es cuando a alguien se le prohbe continuar investigando sobre algo o se le deniega una determinada autorizacin para realizar algo vital para continuar con el desarrollo 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. Pg. 27 de 200
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 se introducen 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 diferencia importante. 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 desarrollo de proyectos confunden planificacin con realizacin ad hoc. Proponen una escuela de direccin de proyecto basada en la idea de planificar a medida que se avanza. Por el contrario, el aprovechamiento de las oportunidades implica una respuesta mesurada ante los desarrollos imprevistos; implica capitalizar lo inesperado. Para que este enfoque tenga xito hay que asegurarse de que el beneficio 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 del producto. Pero en otras ocasiones es meramente una perturbacin y slo produce demoras e injustificados aumentos 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 un verdadero y real control de su proyecto.
LANEGOCIACINENLAESPECIFICACINDELOSREQUERIMIENTOS.
Las personas encargadas de especificar los requerimientos de un proyecto deben enfrentar un conflicto implcito. Por una parte tendrn que especificar todo en detalle para evitar errores de interpretacin por parte del equipo de trabajo. Por otra, los directores de los proyectos deben poseer sensatez suficiente como para mantener las cosas lo ms flexibles posible de modo que el proyecto sea capaz de responder rpidamente a los cambios del ambiente que puedan requerir cambios en las especificaciones. Ambos casos presentan problemas.
PROBLEMASPOREXCESIVAESPECIFICACINDELOSREQUERIMIENTOS.
INFORMACIN INSUFICIENTE: es imposible que una persona tenga toda la informacin necesaria para planificar algo hasta sus ms mnimos detalles. Esto es as porque nadie sabe con exactitud lo que suceder. Si no quieren dejar nada librado al azar, deben conocer en detalle todas las contingencias que pueden surgir durante el curso de la implementacin del proyecto, a fin de elaborar diversos cursos de accin para enfrentarlas. OPOSICIN A LA INICIATIVA PERSONAL: si los planificadores trabajan con demasiados detalles, desalientan la iniciativa personal del equipo de trabajo. Esto traer aparejado dos posibles consecuencias negativas. Una se desalentar la creatividad del equipo de trabajo. La segunda es que las personas no querrn asumir la responsabilidad de dar lo mejor de s. IGNORAR LAS ESPECIFICACIONES: Si stas son demasiado detalladas, es probable que el equipo de trabajo simplemente las ignore. La filosofa de no dejar nada librado al azar puede tener un efecto contrario, ya que los encargados de realizar el proyecto se sentirn abrumados por la exigencia. MANUAL TCNICO PMI - IT REHACER LAS COSAS ES CARO: La excesiva rigidez en la especificacin de los requerimientos puede conducir a una innecesaria y costosa repeticin de partes del trabajo. Inevitablemente habr cambios y estos cambios requerirn que repensemos las especificaciones: si son rgidas y est prohibido desviarse de ellas, es muy probable que en cierto momento la resistencia al cambio se nos vuelva en contra.
Pg. 28 de 200
PROBLEMASPOREXCESIVAFLEXIBILIDAD.
PRODUCTOSEMPARCHADOS: el mtodo de especificar a medida que se avanza puede llevar fcilmente a una falta de coherencia, el producto final ser un conjunto de remiendos reflejando las decisiones ad hoc que se tomaron y no una visin general y abarcadora. PLANIFICACIN CATICA: si nuestros requerimientos son mal definidos y evolucionan arbitrariamente a lo largo de la vida del proyecto, nuestra planificacin ser catica. No tendremos plan alguno que acte como elemento de cohesin. MSTIEMPOYMSCOSTES: un producto emparchado que no satisface las necesidades del cliente puede terminar con el rechazo del producto y la exigencia de que se lo rehaga. Si la excesiva flexibilidad produce una planificacin catica, ello causara a su vez grandes imperfecciones en la implementacin del proyecto.
Vemos, que en lo que se refiere a especificaciones de los requerimientos, los dos extremos son malos. Por lo tanto, debemos buscar un trmino medio, un mtodo que al mismo tiempo evite la rigidez de las especificaciones inflexibles y el caos de las demasiado libres.
Muchos de o problemas vinculados con la especificacin de los requerimientos pueden ser minimizados si las personas involucradas prestan la suficiente atencin a ciertas instrucciones bsicas. REGLA 1: FORMULE CLARAMENTE LOS REQUERIMIENTOS Y HAGA FIRMAR EL DOCUMENTO POR TODOSLOSMIEMBROSDEEQUIPODETRABAJO. Frecuentemente, sobre todo en los proyectos pequeos e informales, los requerimientos no son formulados explcitamente. La enumeracin explcita de los requerimientos tendr el aspecto de un contrato que especifica lo que los clientes quieren y lo que el equipo de proyecto acepta realizar. REGLA 2: SI UN REQUERIMIENTO PUEDE SER MAL INTERPRETADO, SER MAL INTERPRETADO. Al redactar o revisar la redaccin de un requerimiento esfurcese por determinar cmo puede ser mal interpretado. Esto es fundamental realizarlo al inicio del proyecto para evitar sorpresas desagradables en mitad del trabajo o, peor an al terminarlo. REGLA3:RECONOZCAQUEENSUPROYECTOHABRCAMBIOSYQUELASCOSASNOSALDRNTAL COMO LO HABA PLANEADO. La leccin bsica es: prever los cambios y evitar la excesiva rigidez en la formulacin de las especificaciones. REGLA 4: AL FORMULAR LAS ESPECIFICACIONES INCLUYA, EN LA MEDIDA DE LO POSIBLE, FOTOGRAFAS, GRFICOS,MODELOS FSICOS Y OTROS ELEMENTOSNO VERBALES. Un dibujo, grfico, prototipo o diagrama de flujo valen por mil palabras. REGLA 5 ESTABLECER UN SISTEMA PARA CONTROLAR CUIDADOSAMENTE TODOS LOS CAMBIOS QUE SE INTRODUZCAN EN LAS ESPECIFICACIONES. Los sistemas elaborados para rastrear los cambios deben estar dirigidos a dos cuestiones: primero, los proyectos mismos son sistemas, es decir, estn compuestos por partes interrelacionadas. El segundo punto importante es que los cambios cuestan. El coste econmico suele ser obvio, como cuando es preciso desarmar una pieza de un artefacto y rearmarla de otro modo. Pero a veces el coste es ms sutil. Por ejemplo, un cambio conlleva siempre gastos administrativos ocultos. Mientras mayor sea el impacto de un cambio en el sistema en su conjunto, mayor ser la probabilidad de que los costos que acarrea sean considerables. MANUAL TCNICO PMI - IT REGLA 6: ENSELES A LOS MIEMBROS DE SU EQUIPO Y A LOS CLIENTES QU SIGNIFICA ESPECIFICARLOSREQUERIMIENTOS. Una importante causa de problemas es que los equipos inexpertos y los clientes ingenuos ignoran lo que significa crear y satisfacer los requerimientos de un proyecto. Para reducir los problemas causados por ignorancia e ingenuidad, es preciso esclarecer a los clientes y a los miembros del equipo acerca del ciclo vital de las necesidades/ requerimientos. Es preciso que todos tomen conciencia de que los requerimientos constituyen el objetivo hacia el cual se dirige el proyecto.
ORIENTACINGENERALPARALAESPECIFICACINDELOSREQUERIMIENTOS.
Pg. 29 de 200
INSTRUMENTOS Y TCNICAS PARA REALIZAR EL PROYECTO.

La buena planificacin y el control son condiciones necesarias para el xito pero, no son condiciones suficientes para alcanzarlo. Vamos a concentrarnos en las prcticas de planificacin y control ms comnmente aceptadas que se utilizan para realizar proyectos.
EL PLAN DEL PROYECTO.
Un plan de proyecto es bsicamente un mapa de ruta. Consideramos que el plan es el punto de partida de un proyecto: un comienzo, una gua para los desarrollos futuros. Es importante reconocer que un plan es la consecuencia de un gran esfuerzo. El plan surge gradualmente, a medida que se definen las necesidades, se especifican los requerimientos, se hacen predicciones acerca del futuro y se estiman los recursos disponibles. Por lo general, los planes son tridimensionales. Se concentran en el tiempo, el dinero y los recursos humanos y materiales. A lo largo del tiempo se han elaborado instrumentos de planificacin para las tres dimensiones. La dimensin temporal se maneja por medio de agendas, diagramas de Gantt y las redes de programacin, por ejemplo. La dimensin dinero se maneja por medio de presupuestos que nos muestran cmo se distribuirn los fondos de nuestro proyecto. La dimensin de los recursos humanos y materiales se ocupa de la mejor manera de asignar nuestros limitados recursos en un proyecto.
PLANIFICACIN E INCERTIDUMBRE.
La planificacin implica el futuro, y al tratar con el futuro estamos, desde luego, tratando con la incertidumbre. Por lo tanto una realidad fundamental de la planificacin es que implica cierto grado de incertidumbre. Nuestros mejores planes son estimaciones, meras aproximaciones de lo que el futuro puede reservarnos. A veces, la incertidumbre se reduce porque tenemos una amplia experiencia histrica sobre la cual basar nuestras suposiciones acerca del futuro. El carcter del plan est fundamentalmente determinado por el nivel de incertidumbre del proyecto propuesto. Con proyectos que implican bajos niveles de incertidumbre podemos crear planes muy detallados, porque tenemos una buena idea de la forma en que se desarrollar el proyecto. Los proyectos con altos niveles de incertidumbre, por el contrario, no soportan este grado de planificacin detallada, porque hay informacin insuficiente sobre el desarrollo probable de los acontecimientos. En este contexto, cuando hablamos de buena planificacin casi siempre queremos decir planificacin por fases. Primero una planificacin detallada para la fase 1. Luego hacia el final de la fase 1 se inicia la planificacin de la fase 2 y as sucesivamente.
TODO PROYECTO IMPLICA RIESGOS.

El capital a invertir siempre estar sometido a riesgos. Las necesidades del mercado pueden no estar claras y mover a decisiones errneas. Las acciones de la competencia no son fcilmente previsibles y menos an en un mundo globalizado. La realidad econmica, competitiva, poltica, social y cultural de la entidad que realizar la inversin, marcar los criterios que se seguirn para realizar la evaluacin adecuada, independientemente de la metodologa empleada. Los criterios y la evaluacin son parte fundamental de toda evaluacin. El anlisis interno y externo y la evaluacin no eliminan los riesgos, pues el futuro siempre es incierto. Lo que si se logra es eliminar los riesgos de la imprevisin y de no seleccionar la mejor opcin posible.
CONTROLES DEL PROYECTO.

Controlar el proyecto significa examinar el plan, ver lo que est sucediendo verdaderamente en el proyecto, y luego comparar ambas cosas. El propsito del control es mantener el rumbo del proyecto vigilando atentamente su curso. El control cumple su funcin de realimentacin.
Pg. 30 de 200

Una de las realidades fundamentales del Management de proyecto es que habr variaciones entre el plan y los hechos. Debemos tener en cuenta que todos los planes son presunciones, y si bien estas presunciones pueden ser bastante acertadas, es muy improbable que sean perfectas. Nuestra atencin se concentra en determinar si las variaciones, que inevitablemente encontraremos, son razonables o si son desmesuradas. Para eso debemos aceptar criterios de aceptabilidad de las variaciones. Una vez que las hemos establecido, nuestros esfuerzos deben estar dirigidos a revisar las tareas que tienen variaciones excesivas. Hacia el final del proyecto, las variaciones positivas y negativas aceptables que se produjeron en el transcurso de las acciones deben ms o menos neutralizarse mutuamente, dejndonos con una variacin general prxima a cero, si hicimos un buen trabajo de planificacin y control. Sin embargo, aunque podamos aceptar variaciones del 5% respecto del plan, mientras el proyecto est realizndose, no podemos darnos el lujo de aceptar un exceso de coste o de tiempo del 5% para el proyecto en su conjunto. Si estamos dispuestos a aceptar tales excesos generales, debemos construir algo llamado reserva de Management e incorporarlo a nuestro presupuesto.
Cuando se empieza a programar la realizacin de un proyecto, lo primero que se hace es redactar una lista de todas las tareas que se cumplirn. Primero hay que tener una visin amplia y general del proyecto y enumerar las principales fases que hay que encarar. Luego se empiezan a aadir detalles de cada fase, y despus se agregan ms detalles a los detalles. Por lo tanto, se podra decir que el plan del proyecto va tomando forma de arriba hacia abajo, empezando con la descripcin general y avanzando hacia los detalles. Esta forma de trabajo tiene un nombre: work-breakdown structure (WBS) (estructura de anlisis de trabajo). Por lo general, la WBS asume una de dos formas posible: tabla o diagrama. En esta etapa es muy importante hacer una lluvia de ideas, generar una lista, hacer verificacin de calendarios con fechas de posibles fechas de feriados o asuetos, validar la parte las mismas fechas para proveedores externos o de otros pases, as como la parte de vacaciones de los integrantes de los equipos, fechas de posibles entregas de proveedores tercerizados etc.
ESTRUCTURA DE ANLISIS DEL TRABAJO.
DIAGRAMA DE GANTT.
El diagrama de Gantt nos permite ver fcilmente cundo deben empezar y cundo deben terminar las tareas. Cuando se agregan las fechas reales de iniciacin y finalizacin, el diagrama de Gantt es til tambin para el control del proyecto. Luego podemos comparar nuestro plan con los datos reales, y eso nos permitir determinar la magnitud de la variacin en el cronograma, que tengamos en nuestro proyecto. Los diagramas de Gantt se usan mucho para la planificacin y el control de los cronogramas en proyecto. Su popularidad reside en su simplicidad. Es fcil construirlo y comprenderlo.
RED DE PERT / CMP.

La principal desventaja de los diagramas de Gantt es que, si bien representan las fechas de iniciacin y de terminacin de las tareas, no muestra las consecuencias generales de las modificaciones del cronograma en cada tarea especfica. Es decir, el diagrama de Gantt contempla las tareas como si fueran actividades independientes, no tiene en cuenta que estn interrelacionadas. Para subsanar esta falencia se han desarrollado dos tcnicas que permiten a los grupos de trabajo de un proyecto examinar las consecuencias que tiene sobre el cronograma general del proyecto la modificacin de las fechas de iniciacin y de terminacin. Una de ellas es el PERT (Program Evaluation and Review Technique). La otra es el mtodo del Camino Crtico (CPM). Ambos mtodos se basan en diagramas de flujo que parecen similares, pero que contienen un enfoque diferente en los clculos del cronograma. La configuracin de una red PERT/CMP depende, fundamentalmente, de la cantidad de recursos que se puede asignar al proyecto. Por ejemplo, mientras ms gente tenemos, ms actividades paralelas podemos realizar.
LautilidaddelaredPERT/CPMparalaplanificacinyelcontrol
Pg. 31 de 200
Las redes PERT/CPM son muy tiles para la planificacin de proyectos, porque obligan al equipo de trabajo a identificar cuidadosamente las tareas que deben realizarse, y a determinar con precisin la relacin mutua que existe entre stas. Las redes PERT/CPM son tambin tiles en la planificacin, porque permiten a los planificadores elaborar libretos alternativos que les servirn para determinar el impacto que tienen sobre el cronograma general del proyecto, los retrasos y las aceleraciones de las tareas individuales.
LOS INSTRUMENTOS DE PLANIFICACIN Y CONTROL: EL PRESUPUESTO.
Una de las responsabilidades ms importantes del manager de proyecto es elaborar un presupuesto y ceirse a l. Casi siempre el xito o el fracaso del director del proyecto se medir por el hecho de que su trabajo se desarrolle dentro de los lmites del presupuesto o lo supere. Excederse del presupuesto puede tener graves consecuencias para el director del proyecto y para la organizacin dentro de la cual trabaja.
Componentesdelpresupuesto.
Por lo general, el coste de un proyecto se compone de cuatro elementos: costes directos de mano de obra, gastos generales, prestaciones suplementarias y costes auxiliares. 1. 2. 3. 4. LOS COSTES DIRECTOS DE MANO DE OBRA se determinan multiplicando los salarios de los trabajadores por la cantidad de tiempo que se espera dediquen al proyecto. LOS GASTOS GENERALES son los gastos tpicos que se hacen para mantener el ambiente en el que se desempean los trabajadores. LAS PRESTACIONES SUPLEMENTARIAS son beneficios fuera del salario que la organizacin otorga a los empleados. LOS GASTOS AUXILIARES son gastos especficos del proyecto que la organizacin no hace regularmente (gastos de viaje, adquisiciones de equipamiento especial, etc.).
Para los proyectos tecnolgicos, en los que los salarios de los trabajadores del conocimiento suelen ser el componente ms importante del presupuesto, la estimacin del presupuesto est ntimamente vinculada con la estimacin de la cantidad de mano de obra que se necesita para realizar las tareas.
Fondodereserva.
Una lamentable realidad de la direccin de proyecto es la amenaza permanente de que los costes del proyecto superarn el presupuesto. Para enfrentar esta amenaza es comn que los directos de proyecto engorden algo sus estimaciones. Construir un fondo de reserva de entre 5 y 10% es tpico en proyectos de bajos niveles de incertidumbre; en los proyectos de alto riesgo, el porcentaje puede ser mucho mayor.
Como ya se mencion en este captulo, es frecuentemente que el equipo del proyecto descubra que se estn produciendo variaciones, es decir, desviaciones respecto del plan original. Lo importante no es si existe una variacin, sino qu dimensiones tiene. Si una desviacin excede los niveles aceptables, la variacin debe ser identificada y sus causas investigadas. MANUAL TCNICO PMI - IT
Controldelpresupuesto.
CURVA DE COSTES ACUMULADOS.

En la planificacin de proyectos es prctica comn crear un diagrama de gastos acumulados. A ese diagrama se lo llama curva de costes. Las curvas de costes para los gastos planificados y los gastos reales se crean sumando los gastos de cada mes al informe previo de los gastos del perodo. Las curvas de costes acumulados son tiles para controlar las variaciones de coste de un vistazo.
Pg. 32 de 200
INSTRUMENTOS DE PLANIFICACIN Y CONTROL: RECURSOS HUMANOS Y MATERIALES Y SOFTWARE

El objetivo fundamental de la planificacin de los recursos humanos y materiales es la asignacin eficiente y eficaz de recursos al proyecto. El problema fundamental que deben enfrentar los planificadores de recursos es la escasez: la necesidad de recursos sobrepasa a la disponibilidad de recursos. Existe una serie de instrumentos para ayudar a los planificadores de recursos a distribuirlos eficazmente, la matriz de recursos, el diagrama de recursos de Gantt, la hoja de clculo de recursos y el diagrama de cantidad de recursos.
Su funcin consiste en vincular los recursos humanos y materiales para las tareas del proyecto. Se la construye enumerando las tareas que se encuentran en la WBS a lo largo del eje vertical, y enumerando los recursos disponibles a lo largo del eje horizontal. El desarrollo de una matriz de recursos es un primer paso muy conveniente para determinar cmo se asignarn los recursos.
Matrizderecursos.
DiagramaderecursosdeGantt.
La matriz de recursos slo muestra cmo se asignan los recursos a las diferentes tareas; no muestran cmo esos recursos son asignados a lo largo del tiempo. Esto se logra por medio del diagrama de recursos de Gantt.
Lahojadeclculodelosrecursos.
La hoja de clculo de los recursos muestra en forma de tabla la informacin contenida en el diagrama de Gantt de recursos. Al sistematizar una hoja de clculo de recursos, el equipo de trabajo del proyecto puede crear fcilmente muchos libretos alternativos, lo que permite determinar el impacto de las diferentes configuraciones de asignaciones de recursos y seleccionar la mejor configuracin.
Diagramadecantidadderecursos.
El diagrama de cantidad o carga de recursos, tambin llamado histograma de recursos, representa el ciclo de vital del proyecto desde la perspectiva del consumo de recursos. Este diagrama muestra que en las primeras etapas de un proyecto, cuando estamos ponindonos e movimiento, se emplean relativamente pocos recursos; en la etapa intermedia estamos avanzando a toda mquina en la utilizacin de los recursos; y hacia el final del ciclo de vida, nuestro consumo de recursos disminuye. Los diagramas de cantidad de recursos son muy valorados en la direccin de proyectos, porque simplifican la tarea de controlar los recursos.
Nivelacindelosrecursos.
La principal preocupacin de los planificadores de recursos es asignar los recursos humanos y materiales eficiente y eficazmente, es decir, asignar los recursos adecuados a las tareas adecuadas de modo que nunca estn sobre asignados ni subutilizados. La nivelacin de recursos se aplica a la mayora de las situaciones de proyecto. Los planificadores de recursos saben muy bien que cuando se producen dramticas oscilaciones en la demanda de los recursos, algo tiene que ceder, y ese algo es el cronograma del proyecto.
Controlgrficodelosproyectos.
Hasta ahora hemos examinado los principios bsicos de la planificacin y el control de proyectos y hemos discutido sobre los instrumentos de planificacin y control ms utilizados. Examinemos hora la manera de unir estos principios y algunas de las herramientas ms importantes, con el propsito de brindarle al equipo de trabajo del proyecto una metodologa muy poderosa para realizar los controles necesarios. Para tener una visin completa de la marcha del proyecto, el director debe examinar el cronograma, el presupuesto y la asignacin de recursos, todo al mismo tiempo. Cristian Bailey Consultor IT Pg. 33 de 200
Una manera muy eficaz de hacer esto consiste en colocar un resumen grfico del desempeo del cronograma (diagrama de Gantt), del desempeo del presupuesto (curva de costes acumulados) y de las asignaciones de recursos (diagrama de cantidad de recursos) en una sola hoja de papel, de modo que el equipo de trabajo pueda fcilmente comparar el cronograma, el presupuesto y la informacin sobre los recursos. Basndose en estas informaciones amplias y valiosas, los managers de proyectos pueden corregir el curso del trabajo sobre la marcha, ya que disponen de una visin total del estado del proyecto, en lugar de verse limitados a echar un mero vistazo de datos fragmentarios y dispersos.
COMO DIRIGIR PROYECTOS COMPLEJOS Y RESOLVER PROBLEMAS ESPECIALES

LA PLANIFICACIN Y EL CONTROL DE GRANDES PROYECTOS.
Es importante saber cuales son las caractersticas a tener en cuenta para saber si un proyecto debe catalogarse como pequeo o grande, puesto que existen diferencias entre ambos y una de estas diferencias se traduce en la forma de dirigirlos. Las caractersticas bsicas de un proyecto pequeo son: emplea pocos recursos humanos y materiales, es de corto plazo y su foco es ms bien estrecho, es decir, se ocupa de una parte reducida de una gama de actividades que se llevan adelante en una organizacin. Los detalles operacionales estn al alcance de la mayora de los gerentes de proyecto, de modo que casi nunca es necesario exponerlos formalmente. Mientras que, las caractersticas de un proyecto multimillonario son: emplea enormes cantidades de recursos humanos y materiales, es de largo plazo y su foco es amplio. De hecho, por lo general, se establece una organizacin especial para manejar el proyecto. Cuando se trata de un proyecto muy grande, es tanto lo que hay que controlar que se hace necesario establecer un sistema formal y especfico de planificacin y seguimiento que domine todos los desarrollos, tanto planificados como imprevistos. Suele suceder que se dedique ms de la mitad del presupuesto del proyecto a las cuestiones administrativas vinculadas con la planificacin y el control formales.
Lanecesidaddeformalidadenlaplanificacinyelcontroldelosproyectosgrandes.
Si bien las tcnicas anteriormente analizadas funcionan bien tanto en proyectos grandes como pequeos, su exposicin daba por sentado que deban ser usadas con cierta flexibilidad, lo cual es perfectamente ms apropiada para los proyectos pequeos. Sin embargo, este grado de flexibilidad para definir la WBS (work-breakdown structure) no es viable en un proyecto grande, donde quizs haya cien jefes de grupo, cada uno de los cuales crear su parte de una super WBS para el proyecto en su conjunto. Cada uno de estos jefes de grupo debe recibir instrucciones especficas y formales sobre la manera de construir la WBS; de otro modo los resultados de su esfuerzo no concurrirn para formar un super WBS. Lamentablemente, un efecto secundario de la necesidad de mayor formalidad es un aumento de la circulacin de papeles, lo que tiene por objeto mantener las comunicaciones en el equipo del proyecto. En procesos muy grandes existe siempre el peligro de que el equipo de trabajo no pueda separar el grano de la paja, porque casi siempre a esas personas se las bombardea con un exceso de informacin. Esto se torna especialmente importante con respecto al rastreo de los presupuestos y cronogramas. Nos acercamos entonces a un mtodo llamado la tcnica del valor ganado, de gran utilidad para que los equipos de trabajo puedan administrar mejor la informacin sobre presupuesto y cronograma. MANUAL TCNICO PMI - IT
Latcnicadelvalorganado.
Est destinada a ayudar al equipo del proyecto a hacer un mejor seguimiento de lo que esta sucediendo. Reconoce que los datos de los costes solos, o los datos del cronograma solos, pueden llevar a una percepcin distorsionada del desempeo del proyecto. Habamos visto que este problema puede manejarse consultando los diagramas de Pg. 34 de 200
Gantt, las curvas de costes acumulados y los diagramas de cantidad de recursos. Sin embargo, la aplicacin de este mtodo a proyectos muy grandes, con gran cantidad de actividades, superara totalmente las posibilidades de cualquier equipo de trabajo. El mtodo del valor ganado permite a los profesionales examinar las variaciones de costes y de planificacin al mismo tiempo y en forma numrica, y eso facilita tener una visin holstica del progreso del proyecto. La tcnica del valor ganado se basa en tres bloques fundamentales. Uno se llama el BCWS (coste presupuestado de trabajo planificado). Es equivalente al concepto convencional de presupuesto planificado, es decir, que el BCWS expresa lo que nosotros pensamos que costar determinada tarea o paquete de trabajo. El segundo bloque se llama el ACWP (Coste real del trabajo realizado) Esta idea es equivalente al concepto convencional de costes reales, es decir, que el ACWP expresa cunto gastamos realmente para realizar determinado trabajo. La tcnica del valor ganado se torna interesante con la introduccin del concepto BCWP (coste presupuestado del trabajo realizado) conocido tambin como valor ganado. El coste presupuestado de este trmino significa que nos preocupamos por nuestro plan original, mientras que el trabajo realizado se refiere a lo que se ha logrado realmente. As, el BCWP o sea el valor ganado es una medida hbrida que combina elementos del plan con elementos de los datos reales. Con el BCWP evaluamos nuestro desempeo real en funcin de lo que originariamente habamos planificado realizar. Estos tres elementos (BCWS, ACWP y BCWP) nos permiten calcular la varianza del presupuesto y el cronograma de una manera nueva y poderosa. Una debilidad fundamental en la tcnica del valor ganado es que para calcular el BCWP es necesario conocer el porcentaje de una tarea que se ha completado. Cuando tratamos de estimar qu parte de una tarea se ha completado, entre dos extremos, empezamos a transitar un terreno peligroso. Si es difcil saber qu parte de una parte tarea se ha completado cuando estamos tratando con empresas tangibles y a ras de tierra, consideremos el nivel de dificultad que plantea hacer una estimacin semejante en proyectos de tecnologa informtica, que operan sobre todo en el mbito de lo intangible. El mtodo del valor ganado tiene un medio para encarar este problema: la regla del 50-50. Inmediatamente se inicia una tarea se supone que se ha completado la mitad del esfuerzo, y se ingresa en el libro de contabilidad del proyecto la mitad del valor del BCWS asociado con la tarea en cuestin. Slo despus de que se ha completado la tarea, se ingresa de contabilidad la otra mitad del valor BCWS. Cuando se estn considerando muchas tareas, este mtodo proporciona una buena aproximacin estadstica del BCWP. Muchos expertos en direccin de proyectos creen firmemente que el mtodo del valor ganado es vital para el control de los proyectos muy grandes. Tambin puede resultar til para los proyectos pequeos, aunque para estos ltimos no es necesario seguir reglas tan estrictas. Todo lo que necesitamos para poner en prctica el sistema del valor ganado es poseer estimaciones adecuadas de los costes de las tareas planificadas (BCWS), datos sobre los gastos reales (ACWP) y una estimacin bastante aproximada del porcentaje de trabajo completado hasta el momento (un mtodo riesgoso), o bien el empleo de la regla del 50 50.
Planificacinycontrolparaproyectosmltiples.
Muchas veces los proyectos se organizan en un portafolio, es decir, un conjunto de proyectos que deben ser administrados al mismo tiempo. MANUAL TCNICO PMI - IT Podemos encontrarnos con portafolios de proyectos en muchas situaciones diferentes. Por ejemplo, en los departamentos de procesamiento de datos, en los de investigacin y Desarrollo, en los departamentos contables y las agencias de publicidad.
EL PORTAFOLIO DE PROYECTOS.
Los portafolios de proyectos pueden presentarse en muchas diferentes formas y tener tamaos diversos. Puede existir un portafolio de proyectos que se ocupan todos del mismo tema bsico, pero que son independientes entre s; el resultado de un proyecto tiene escasa o ninguna influencia sobre el trabajo en los otros proyectos. Lo que une al Cristian Bailey Consultor IT Pg. 35 de 200
proyecto es un fuerte proceso de seleccin de proyectos que filtra todas las posibilidades de proyectos que no tiene nada que ver con la misin. Otra posibilidad es que el portafolio constituye lo que suele llamarse un programa. Su principal caracterstica es la fuerte independencia de los proyectos que componen el portafolio. Estos proyectos diferentes se unen y se dirigen hacia un resultado comn. Este tipo de portafolio requiere una vigilante planificacin y un control estricto que abarque la totalidad de los proyectos. Otro caso, puede ser de un portafolio que no sea ms que una yuxtaposicin de proyectos que poco o nada tienen en comn. La planificacin y el control son responsabilidad de los diferentes gerentes de proyecto.
Algunasconsideracionesespecialessobrelaadministracindeunportafolio
Es mucho ms complejo dirigir un portafolio de proyectos que dirigir un solo proyecto. Veamos algunas de las razones de que esto sea as. Los portafolios son administrativamente ms complejos que los proyectos nicos. La optimizacin del desarrollo del portafolio requerir una sub optimizacin de los proyectos individuales. El objetivo del gerente de portafolio es optimizar la realizacin del portafolio, y eso exige invariablemente que las decisiones que tome respecto de la asignacin de recursos y la planificacin beneficien a los proyectos de primera prioridad, a expensas de los proyectos de prioridad secundaria. Es difcil mantener constantemente un punto de vista equilibrado sobre los proyectos grandes y pequeos que suelen coexistir en un portafolio. Por definicin, los proyectos grandes tiene un perfil ms pronunciado que los proyectos pequeos: son ms visibles. Los proyectos tienden a tener acceso a lo mejor de los recursos escasos. Cuando los proyectos grandes tienen problemas, los proyectos pequeos del portafolio suelen verse sumamente perjudicados en el proceso.
Lasecuenciadelosproyectosdentrodelportafolio
La secuencia de los proyectos dentro de un portafolio puede tener una gran influencia sobre el desarrollo general de los trabajos. Tambin tiene influencia sobre el flujo de beneficios que surgen de ellos.
Anlisisdelabrecha
En el captulo anterior se analizaron las dificultades inherentes a la confeccin de un presupuesto para un proyecto nico. Las asignaciones presupuestarias para un portafolio de proyectos mltiples presentan dificultades an mayores. El anlisis de la brecha es una tcnica que suele resultarles muy til a los profesionales para visualizar las opciones presupuestarias prcticas de que disponen en los portafolios de proyectos. El mtodo de anlisis de la brecha utiliza previsiones exploratorias y normativas. En el caso de las previsiones normativas, examinamos un futuro estado de cosas y nos preguntamos: qu debemos hacer para llegar a este punto? Con las previsiones exploratorias extrapolamos de las experiencias y proyectamos hacia el futuro. Una vez elaborados los presupuestos individuales, se los suma y se genera as un presupuesto total para los proyectos que componen el portafolio. En el anlisis de la brecha, la curva vinculada a las exigencias del presupuesto total de los proyectos existentes se compara con una curva del presupuesto total anticipado para todos los proyectos, incluidos aquellos que todava no han comenzado. El anlisis de la brecha no proporciona una respuesta automtica a la pregunta de cmo debe construirse el portafolio, pero puede servir como un instrumento til para conceptualizar el futuro carcter del portafolio. "Situsaccionesinspiranaotrosasoarms,aprenderms,hacermsysermejores,eresunlder" MANUAL TCNICO PMI - IT
Pg. 36 de 200
PLANIFICACIN Y CONTROL DE PROYECTOS POR CONTRATO.

Muchos proyectos se realizan por contratos. Desde luego, el mayor financista de los contratos para los proyectos es el gobierno. Tambin el sector privado trabaja por contrato. Compaas grandes y pequeas utilizan asesoramiento externo para realizar obras que no podran emprender con sus recursos propios. Cuando hablamos de la direccin de proyectos por contrato, agregamos una nota ms de complejidad a una situacin que es ya de por s compleja. En este caso, los clientes estn fuera de la organizacin que realiza el trabajo. Estos clientes, que pagan un dinero para obtener ciertos resultados, estn siempre interesados en sacar beneficio de su inversin en el proyecto. Por lo tanto, casi siempre insisten en desempear un papel activo en la supervisin del progreso y, de hecho, sienten que ellos son los verdaderos gerentes del proyecto.
Tiposdecontrato.
Un contrato es un acuerdo legal que especifica los derechos y responsabilidades de las partes contratantes. Los contratos pueden adoptar formas muy diversas. Nos concentraremos ms bien en los dos tipos ms comunes de proyecto por contrato: de precio fijo y del tipo coste-ms.
Contratosdepreciofijo.
Con un contrato de precio fijo, el financiador y el realizador negocian un precio estipulado para realizar el proyecto. El realizador acuerda hacer lo que se describe en el contrato por un precio total e inamovible. Si el realizador puede llevar adelante el trabajo que demanda el proyecto a un coste menor que el precio fijado, obtiene una ganancia, pero si le cuesta, ms de lo previsto, entonces enfrenta una prdida. En teora, los contratos de precio fijo colocan las responsabilidades de la direccin totalmente en manos del realizador. Lo nico que el ente financiador tiene que hacer es sentarse a esperar los resultados en la fecha prometida. Pero, en la prctica, el financiador debe vigilar el trabajo del realizador. Un contrato de precio fijo es un acuerdo, no una garanta de que el producto ser entregado a tiempo y en las condiciones acordadas. Las organizaciones experimentadas tratan de no hacer contratos de precio fijo para proyectos no rutinarios y no predecibles. Y, si contratan un proyecto riesgoso por un precio fijo, agregan una bonificacin por alto riesgo que aumenta generosamente las estimaciones de los costes del proyecto con el propsito de prever contingencias inesperadas.
Contratosdecostems.
En este caso, el financiador acepta remunerar el trabajo del realizador del proyecto y ofrece, adems, una bonificacin adicional, de modo que la organizacin obtenga unas ganancias por sus esfuerzos. Estos contratos se firman sobre proyectos muy especulativos: proyectos sobre los que es difcil o imposible predecir acertadamente cunto costarn. Los profesionales de proyecto de la organizacin contratada sufren menos presiones con los contratos de coste-ms extras que con los contratos de precio fijo. Con los contratos de coste-ms extras, existe siempre el peligro de que el realizador afloje el control de la obra. Controlados errneamente es fcil que los gastos se vayan de las manos. Si bien es fundamental que la organizacin que financia haga un seguimiento de la marcha del proyecto, es preciso evitar una intervencin tan fuerte que pueda provocar el fracaso del proyecto.
Comomanejarloscambiosenelplandelosproyectosporcontrato.
Sin una posicin explcita para encarar los pedidos de modificaciones, los gerentes de proyecto recientemente iniciados pueden llegar a tener graves problemas. En su deseo de complacer al cliente, pueden llegar a acceder a introducir pequeos cambios aqu y all. Pero poco despus se darn cuenta de que esos pequeos cambios van sumando dlares y reduciendo su margen de ganancias.
Pg. 37 de 200
Los gerentes de proyectos deben contar con que en el plan se producirn cambios. En los proyectos contratados de precio fijo, los gerentes de proyecto deben utilizar conscientemente una metodologa explcita para atender los pedidos de modificaciones del financiador, ya que, casi siempre, esos cambios aumentan el coste del proyecto.
Es mucho mejor que los contratistas del proyecto pongan en claro desde el comienzo que todo cambio solicitado por el cliente ser registrado y cobrado. Esta poltica obligar al cliente a pensarlo dos veces antes de pedir un cambio. Adems, este mtodo evitar que el gerente de proyecto de la organizacin que realiza la obra se vea en una situacin de pasar de una actitud complaciente a un duro rechazo ante las solicitudes del cliente.
Planificarycontrolarconmetasburocrticas.
En general, los proyectos financiados por el gobierno son ms difciles de manejar que sus equivalentes del sector privado. Esto se debe fundamentalmente al hecho de que gran parte del proceso de direccin de los proyectos est regida no por el buen sentido, sino por normas y reglamentaciones que, dentro del contexto de determinados proyectos, puede parecer arbitraria e insensata. Una clave importante para minimizar los problemas en los proyectos gubernamentales es el conocimiento de los aspectos legales y administrativos del procedimiento contractual. El material instructivo de los gerentes de proyectos se concentra, por lo general, en una optimizacin del cronograma o en una optimizacin de los recursos. Pero en muchas organizaciones burocrticas la buena planificacin tiene menos que ver con el cronograma o la optimizacin de los recursos que con la identificacin de las metas burocrticas clave de importancia para la organizacin y con el establecimiento de una secuencia de las tareas que permita ir alcanzando esas metas a tiempo. Estas etapas burocrticas estn con frecuencia vinculadas con el ciclo presupuestario de la organizacin. Los tcnicos suelen prestar poca atencin a las cuestiones burocrticas. Lo ms comn es que simplemente ignoren los plazos o no cumplan con los requisitos de los hitos burocrticos hasta el ltimo momento posible. El equipo de proyecto que llega a dominar los vericuetos de la burocracia, puede utilizar ese conocimiento para construir una autoridad en el campo burocrtico que le ayudar a negociar sus proyectos a travs del laberinto de las exigencias burocrticas.
COMO ALCANZAR BUENOS RESULTADOS. PRINCIPIOS PARA TRIUNFAR COMO GERENTE DE PROYECTO.
Un problema muy comn que enfrentan los especialistas en direccin de proyectos es que se involucran tanto en su trabajo y se concentran de tal modo en las minucias, que pierden de vista la perspectiva general del trabajo. Los principios ms rudimentarios que debemos tener en cuenta para maximizar las posibilidades de llevar nuestro proyecto a un final feliz son los siguientes: 1.- TENGA CONCIENCIA DE LO QUE EST HACIENDO: no sea un director accidental. Hombres y mujeres tropiezan con la responsabilidad de dirigir un proyecto accidentalmente y tienen slo un vaga conciencia de lo que son los proyectos y de cmo hay que dirigirlos. Entonces adoptan el mtodo de ensayo y error. Gran parte de las dificultades que los gerentes de proyecto encuentran podran evitarse si ellos simplemente hicieran el esfuerzo de aprender algo acerca de la teora y la prctica de la direccin de proyectos. 2.- INVIERTA MUCHO EN EL TRABAJO INICIAL: empiece bien desde el principio. En un proyecto, hacer las cosas bien desde el principio es siempre conveniente. Pero hacer las cosas bien requiere tiempo y esfuerzo. Para la gente impetuosa, es ms satisfactorio lanzarse al proyecto y empezar a resolver los problemas a medida que se presentan, que identificar con precisin cules son esos problemas. Lamentablemente, si al comienzo de un proyecto no se realiza ese penoso trabajo inicial, es muy probable que las diversas tareas que componen el proyecto no se realicen adecuadamente; ser necesario volver a efectuarlas hasta que el proyecto finalmente tome un rumbo. Pero volver a realizar una tarea es caro. 3.- PREVEA LOS PROBLEMAS QUE INEVITABLEMENTE SURGIRN: Los conflictos y los problemas son inherentes a los proyectos y, por lo tanto, es inevitable que aparezcan. Pero si prevemos esos problemas, podremos determinar con tiempo cmo encararlos, y mientras ms experiencia adquirimos como gerentes de proyecto, hasta podemos llegar a utilizarlos en nuestro beneficio. 4.- NO SE DEJE ENGAAR POR LAS APARIENCIAS: examine las cosas a fondo para descubrir la verdadera situacin. Los gerentes de proyecto estn continuamente en problemas porque aceptan las cosas como se les presentan a primera Cristian Bailey Consultor IT Pg. 38 de 200
vista. En la medida en que los directores de proyecto no comprendan lo que est sucediendo realmente en su trabajo, es muy posible que corran detrs de las sombras. As nunca tomarn decisiones acertadas. 5.- SEA LO MS FLEXIBLE POSIBLE: no se deje ganar por una rigidez y una formalidad innecesarias. El gerente de proyecto trata de crear un orden donde el estado natural de las cosas parece ser el caos. En nuestra lucha por generar orden, sin embargo, corremos el riesgo de sacrificar una razonable flexibilidad en el altar de las exigencias formales del proyecto. Muchas veces la gente no entiende que se puede alcanzar el orden sin excesiva formalidad. Si somos conscientes de lo que estamos haciendo en un proyecto y tratamos de no ser gerentes de proyecto accidentales, si invertimos en un trabajo inicial duro y eficiente, si prevemos los problemas inevitables y si penetramos por debajo de las apariencias, podremos poner orden en nuestro proyecto. Y si, adems, rechazamos la innecesaria formalidad y la rigidez es factible que podamos tener orden y flexibilidad al mismo tiempo. Ciertos proyectos requieren un alto grado de formalidad, por ejemplo, los proyectos de bajo riesgo. Teniendo en cuenta el menor tamao de los proyectos tpicos de la era de la informacin y su elevado grado de incertidumbre, la necesidad de una formalidad rgida para dirigirlos es usualmente baja, por lo tanto, en la mayora de los casos, la gran formalidad no es conveniente.
LAS COMPETENCIAS BSICAS DEL MANAGER DE PROYECTO.

Para cualquier organizacin, hacer ms con menos es importante. Para alcanzar este objetivo, es preciso que la mano de obra est constituida por gente altamente calificada: personas que no slo conozcan los aspectos tcnicos de su trabajo, sino que, adems sean buenos realizadores. Esta preocupacin por identificar a los buenos trabajadores y alentarlos produjo una tendencia conocida como movimiento de las competencias bsicas. El PMI identific ocho competencias fundamentales que el buen profesional de proyectos debe dominar: Management de campo de accin (por ejemplo, construccin de WBS, interpretacin del ciclo vital del proyecto). Management del tiempo (construccin de cronogramas con diagramas de Gantt) Management del coste (buen empleo de las metodologas de estimacin de los costes, elaboracin de presupuestos). Management de los recursos humanos (manejo de los conflictos, motivacin de los recursos de matriz) Management del riesgo (identificacin y modelacin del riesgo, planificacin para el riesgo) Management de la calidad (identificar quines son los clientes, hacer las cosas bien la primera vez) Management del contrato (entender los procesos de contratacin y tramitacin, resolver disputas) Management de la comunicacin (entender la influencia de los diferentes vehculos de comunicacin, evitar las interrupciones de la comunicacin). Entre otras tambin son consideradas de gran importancia, las siguientes capacidades en los Directores de Proyectos: Liderazgo. Capacidad tcnica. Generalista con base tcnica. Capacidad para controlar. Objetivos, resultados esperados, personas, presupuesto y acciones. Tener criterio para compaginar soluciones tcnicas con intereses, plazos, costos y otros factores humanos. Capacidad de adaptacin. Capacidad de identificacin de problemas relevantes Cada una de ellas es de gran importancia en el comportamiento del manager y va a facilitar que el desarrollo del proyecto en cuestin sea viable. REFLEXIN: "La magnitud de un lder est dada por la profundidad de sus convicciones, el gradodesusambiciones,elngulodesuvisinyelalcancedesuamor" Pg. 39 de 200
CAPITULO 2 ETAPAS DE LOS PROYECTOS Y SUS COMPONENTES. GESTIN DE PROYECTOS.
REFLEXIN: "Lahabilidadesloqueerescapazdehacer.Lamotivacindeterminaloquehars.Laactitud determinalobienquelohars"
Pg. 40 de 200
PLANIFICACIN Y CONTROL
ETAPAS DE UN PROYECTO.
Desde un punto de vista muy general puede considerarse que todo proyecto tiene tres grandes etapas: FASE DE PLANIFICACIN. Se trata de establecer cmo el equipo de trabajo deber satisfacer las restricciones de prestaciones, planificacin temporal y coste. Una planificacin detallada da consistencia al proyecto y evita sorpresas que nunca son bien recibidas. FASE DE EJECUCIN. Representa el conjunto de tareas y actividades que suponen la realizacin propiamente dicha del proyecto, la ejecucin de la obra de que se trate. Responde, ante todo, a las caractersticas tcnicas especficas de cada tipo de proyecto y supone poner en juego y gestionar los recursos en la forma adecuada para desarrollar la obra en cuestin. Cada tipo de proyecto responde en este punto a su tecnologa propia, que es generalmente bien conocida por los tcnicos en la materia. FASE DE ENTREGA O PUESTA EN MARCHA. Como ya se ha dicho, todo proyecto est destinado a finalizarse en un plazo predeterminado, culminando en la entrega de la obra al cliente o la puesta en marcha del sistema desarrollado, comprobando que funciona adecuadamente y responde a las especificaciones en su momento aprobadas. Esta fase es tambin muy importante no slo por representar la culminacin de la operacin sino por las dificultades que suele presentar en la prctica, alargndose excesivamente y provocando retrasos y costes imprevistos. A estas tres grandes etapas es conveniente aadir otras dos que, si bien pueden incluirse en las ya mencionadas, es preferible nombrarlas de forma independiente ya que definen un conjunto de actividades que resultan bsicas para el desarrollo del proyecto: FASE DE INICIACIN. Definicin de los objetivos del proyecto y de los recursos necesarios para su ejecucin. Las caractersticas del proyecto implican la necesidad de una fase o etapa previa destinada a la preparacin del mismo, fase que tienen una gran trascendencia para la buena marcha del proyecto y que deber ser especialmente cuidada. Una gran parte del xito o el fracaso del mismo se fragua principalmente en estas fases preparatorias que, junto con una buena etapa de planificacin, algunas personas tienden a menospreciar, deseosas por querer ver resultados excesivamente pronto. FASE DE CONTROL. Monitorizacin del trabajo realizado analizando cmo el progreso difiere de lo planificado e iniciando las acciones correctivas que sean necesarias. Incluye tambin el liderazgo, proporcionando directrices a los recursos humanos, subordinados (incluso subcontratados) para que hagan su trabajo de forma efectiva y a tiempo.
Los periodos generales de duracin los podemos ver a continuacin:
Pg. 41 de 200
Estas etapas citadas presentan, sin embargo, caractersticas bastante diferentes segn se trate de proyectos internos o de proyectos externos. Las principales diferencias aparecen en la etapa de planificacin. En el proyecto externo existen un conjunto de acciones que se relacionan con la necesidad de presentar una oferta al cliente y lograr la adjudicacin del contrato en competencia con otras empresas o personas. Si, por la razn que fuere, el contrato no se consigue el proyecto queda abortado antes de haberse comenzado y carece de sentido preocuparse de cmo debe ser gestionado. La exigencia comercial tiene, pues, un carcter prioritario para las empresas, siendo la consecucin del contrato paso imprescindible para poder acometer un proyecto concreto y, con una perspectiva ms amplia, condicin esencial para la supervivencia de la empresa. Puedes ver ms sobre la importancia del perfil comercial en el apartado de oferta. Haciendo referencia a las tres grandes etapas nombradas al principio, podemos ver la diferencia entre ambos tipos de proyectos:
Cuando se abordan proyectos grandes y complejos, la consecucin del resultado final depende de la realizacin armnica del conjunto de las etapas pertinentes con ayuda de los medios materiales y humanos requeridos en cada momento. La concepcin de las fases que han de ejecutarse, el orden de encadenamiento lgico de las mismas y la estimacin de la naturaleza y cantidad de recursos a emplear en cada momento, precisan de un conocimiento profundo de las tecnologas que concurren en el proyecto y de una experiencia que permita prever y superar las dificultades que en la prctica suelen aparecer. A continuacin se presentan las distintas etapas en el desarrollo de una aplicacin informtica: ETAPA 1: NACIMIENTO DE LA IDEA DEL PROYECTO: El "cliente o promotor" expone sus necesidades y el deseo de resolver el problema por medios informticos. Se crea un primer documento breve que recoge el anteproyecto y es aprobado por la direccin o el comit correspondiente. ETAPA 2: ESTUDIO DE OPORTUNIDAD: El estudio de oportunidad concreta los objetivos y resultado a aportar por el proyecto, los plazos y costes previstos y los medios a emplear.
Pg. 42 de 200
ETAPA 3: ESTUDIO DETALLADO: El jefe de proyecto define, ya en detalle, con el apoyo de los tcnicos de su equipo, el contenido del proyecto, su anlisis funcional, las cargas de trabajo previsto y la metodologa a desarrollar. ETAPA 4: CUADERNO DE CARGAS PARA INFORMTICA: A partir del anlisis funcional se determinan en forma definitiva los volmenes, cargas de trabajo, calendario y medios a utilizar, dando lugar al contrato formal entre cliente, usuarios e informticos, frecuentemente conocido con el nombre de cuaderno de cargas o, ms concretamente, "pliego de especificaciones". ETAPA 5: ANLISIS ORGNICO: Los tcnicos realizan el anlisis orgnico y las especificaciones para programacin. ETAPA 6: PROGRAMACIN Y PRUEBAS: Se realiza la programacin de la aplicacin y las pruebas para programacin. ETAPA 7: RECEPCIN PROVISIONAL: Al resultar satisfactorias las pruebas se realizan la recepcin provisional, dando lugar a los manuales de usuario y de explotacin. ETAPA 8: PUESTA EN MARCHA: La puesta en marcha de la aplicacin es una fase delicada que requiere una estricta vigilancia hasta comprobar su correcto funcionamiento. A continuacin se realiza un balance de los resultados del proyecto. ETAPA 9: BALANCE DE FUNCIONAMIENTO: Despus de varios meses de funcionamiento de la aplicacin se debe realizar un balance que permita apreciar los beneficios que realmente ha producido a la empresa. ETAPA 10: AUDITORA: Transcurridos uno o dos aos, debe efectuarse una auditora de la aplicacin que permita comprobar si sigue siendo adecuada o si es necesario introducir modificaciones. Desde el punto de vista de la metodologa de gestin de proyectos, tambin pueden identificarse varias fases que generalmente debern darse en todo tipo de proyectos: 1. Decisin de acometer el proyecto. 2. Nombramiento del jefe de proyecto. 3. Negociacin de objetivos. 4. Preparacin. 5. Ejecucin. 6. Informacin. 7. Control. Dentro de la preparacin, se integraran actividades como la descripcin de actividades, identificacin de recursos, valoracin de los mismos -presupuesto-, planificacin y eventual reconsideracin de los objetivos.
LA OFERTA.
El primer objetivo que aparece antes de acometer un proyecto es el de presentar una oferta con el fin de conseguir el contrato, es decir, convencer al cliente de que nuestra propuesta es ms adecuada que la de los competidores, ya sea en el aspecto tcnico, ya sea en las condiciones ofrecidas en cuanto a coste o plazo, sin olvidar la influencia que en la decisin del cliente suelen tener otros elementos menos objetivos, pero no por ello menos reales, como son la imagen de la empresa, las referencias anteriores, la confianza en las personas, etc. Dada la importancia de esta labor comercial y el hecho de que en muchos casos las personas con un perfil ms tcnico no suelen destacar por sus aptitudes comerciales, es muy frecuente que la organizacin de la empresa separe en rganos o personas diferentes la tarea de realizar y negociar la oferta de la labor de dirigir y ejecutar el proyecto. Y es aqu donde surge el primer conflicto, pues el comercial, en su fin de obtener el contrato, puede ofrecer una serie de condiciones y seguridades que posteriormente el tcnico considerar imposible de respetar. Cristian Bailey Consultor IT Pg. 43 de 200
Este antagonismo entre las facetas tcnica y comercial de la oferta es algo que muy pocas empresas tienen totalmente superado. La dificultad radica precisamente en que la oferta tiene inevitablemente la doble caracterstica de documento tcnico y comercial. Tan negativo es realizar un oferta excepcional desde el punto de vista tcnico y no conseguir el contrato, como ofrecer "el oro y el moro" para hacerse con l y luego no poder respetarlo.
FINALIDAD COMERCIAL.
Como hemos dicho, la oferta tiene ante todo una finalidad comercial. Ello implica la necesidad de respetar al menos los siguientes principios: Captar bien el inters y la necesidad del cliente. Ofrecer lo que el cliente pide pero sin olvidar orientarle hacia lo que creemos que necesita o lo que sera conveniente ofrecerle. Hacer una oferta clara, atractiva para el cliente, bien concebida y presentada, completa. Dedicar el tiempo y el cuidado precisos para garantizar la calidad de la oferta. Sintonizar con el inters, la terminologa y la mentalidad del cliente. Destacar las ventajas de nuestra propuesta y los aspectos positivos que puedan interesar al cliente. Aportar todos los elementos que puedan enriquecer la oferta y dar confianza al cliente: fotografas, esquemas, referencias, ejemplos, muestras, etc.
ORIGEN TCNICO.
Toda oferta supone en el caso de un proyecto imaginar el resultado final de la obra, los recursos que va a ser necesario emplear y, consecuentemente, la solucin tcnica que se va a desarrollar. El plazo de realizacin, presupuesto, calidades, etc. sern precisamente consecuencia de esa solucin tcnica concebida. Desde el punto de vista tcnico, tambin es aconsejable seguir una serie de normas o principios a la hora de elaborar la oferta: Incluir una solucin tcnicamente correcta, viable y coherente con las necesidades del cliente. Concretar suficientemente las especificaciones tcnicas que habr de respetar la obra y que permitirn controlar su calidad. Aadir los planos o documentos necesarios para identificar claramente las caractersticas de la obra. Contemplar todos los datos importantes que el cliente precisa para poder tomar una decisin: calidades, plazos, costes, formas de pago, aportacin a efectuar por el propio cliente, servicio postventa, garantas. Identificar con claridad los compromisos que se adquieren mutuamente.
A menudo se argumenta que realizar una oferta tan clara puede resultar perjudicial para la faceta tcnica. Sin embargo, los clientes, cada vez ms exigentes en este aspecto, siempre agradecen y valoran muy positivamente una oferta tcnicamente bien hecha, donde quede claro a qu se comprometen ambas partes. Es verdad que hacer bien una oferta lleva tiempo y dinero, pero se debe entender como una inversin muy rentable, ya que lo que ahora se gaste ms tarde se ahorrar con creces en conflictos y en prdidas imprevistas.
LOS PROYECTOS INTERNOS.

Lgicamente, en los proyectos internos no se presenta en la misma forma esta necesidad de realizar una oferta previa y redactar un contrato formal. S es conveniente analizar detenidamente el proyecto, con sus diversos grados de necesidad, con las diversas opciones tcnicas existentes, contemplando si se dispone de los recursos financieros y humanos precisos y eligiendo entre los diversos proyectos que se pudiesen acometer. Tambin resulta aconsejable en estos casos que la formulacin del proyecto, una vez adoptado las decisiones previas, se refleje en un documento que, pudiendo ser simple y breve, recoja con claridad los objetivos del proyecto. Ahora la faceta comercial queda relegada a un lado, y se busca un pseudo contrato que sirva como marco de referencia a la relacin entre organizacin y jefe de proyecto.
Pg. 44 de 200
LOS OBJETIVOS.
Un principio bsico de en la gestin de proyectos, as como en toda actividad de gestin, es que los objetivos estn definidos a priori y con un grado de suficiente de claridad y precisin. Hay proyectos donde la definicin de objetivos se hace realmente difcil, pero esa dificultad no significa que no deba hacerse, puesto que cuanto ms inmaterial es o ms arriesgado sea un proyecto ms necesario ser contar con un marco de referencia, aunque sus contornos sean menos ntidos que en otras ocasiones. OBJETIVO TRIPLE: Resultado, Coste, Plazo. El objetivo del proyecto es siempre triple. No basta con conseguir uno o dos objetivos, ni hay que dar ms importancia a uno o a otro.
El primer objetivo es el resultado final de proyecto, es decir, la obra que se quiere realizar y que supone el origen y justificacin del proyecto, por lo que puede considerarse el objetivo ms importante y significativo. Pero la consecucin del objetivo tcnico no es suficiente. Eso s: ha de considerarse ms bien como una condicin ineludible. En el caso de abordar la electrificacin de una aldea, la aldea se debe electrificar, pero a cualquier precio ni en cualquier plazo. En el caso de proyectos externos, el objetivo de coste suele estar definido y tiene una importancia grande. Normalmente existe un contrato, y el proveedor deber respetarlo o tendr dificultades para revisar al alza el presupuesto. En proyectos internos es frecuente que el objetivo de coste no figure en forma explcita, algo que se debe intentar reducir. El plazo es el objetivo que ms fcilmente se deteriora, convirtindose as en el que mejor mide el grado de calidad de gestin del proyecto. A menudo se piensa que el plazo de realizacin de un proyecto no debe valorarse excesivamente, puesto que es algo que "casi nunca se respeta". Pero hay proyectos en los que este objetivo se convierte en el ms importante. Qu pasara si las obras del estadio olmpico no estuvieran terminadas para la inauguracin de los Juegos Olmpicos? El aspecto triangular de los objetivos se refuerza por la necesidad de coherencia y proporcin entre los mismos. Los tres son inseparables y forman un sistema en el que cada modificacin de cada una de las partes afecta a las restantes. Dado que la maximizacin individual de los tres criterios bsicos no es posible, es necesario maximizar una cierta combinacin entre ellos, priorizando aquellos que se adapten mejor a las estrategias de la empresa.
Pg. 45 de 200
La combinacin no es nica y, de hecho, puede pensarse en una zona de validez de la aproximacin seguida. La figura representa esa zona en la que el proyecto puede moverse dentro de la disponibilidad de recursos existente. Con ello, se quiere indicar tambin que no existe una nica forma posible de gestionar un proyecto satisfaciendo los requisitos bsicos. Un ahorro en costes (dentro de la zona permitida) permitira abordar otras actividades que mejoren, por ejemplo, la satisfaccin del cliente. Las tcnicas de gestin de proyectos deben considerar adems las actuaciones relacionadas con las desviaciones de la zona objetivo durante el desarrollo del proyecto y, por tanto, la aplicacin de medidas correctoras para evitar problemas adicionales. Ello implica ser capaces de monitorizar el cumplimiento de los objetivos identificados de forma continua (en la prctica en determina dos hitos, o puntos de control del proyecto en los que hay que tener determinada visibilidad de resultados intermedios).
EL CUARTO OBJETIVO.
Algunos autores introducen un cuarto elemento de gran inters: la satisfaccin del usuario. Con ello se quiere indicar la importancia de que el proyecto satisfaga las expectativas de ste. Un proyecto que cumpla las especificaciones, se realice en tiempo y dentro del presupuesto pero que no deje satisfecho al cliente no cumple sus objetivos. La satisfaccin del cliente suele considerarse ahora como una estrategia general de muchas empresas (sobre todo de las de servicios) y elemento clave para la valoracin del xito de los proyectos que emprendan.
CONTEXTO Y ESTRATEGIA.
Un proyecto no puede concebirse al margen del resto de las actividades que lleva a cabo la organizacin. Todas las actividades contribuyen a conseguir unos fines generales expresados en las estrategias de la organizacin. Por ello, el tipo de organizacin influye no slo en los proyectos que se van a a realizar sino tambin en la forma en la que se realizan. Todo ello forma parte del contexto del proyecto. El conocimiento del contexto del proyecto es un elemento fundamental para asegurar el cumplimiento de sus objetivos. Como se ha dicho, la gestin del proyecto deber buscar el ptimo entre los objetivos. Para ello hay que conocer la importancia relativa de cada factor respecto a cmo responde a la estrategia de la organizacin ejecutora del proyecto. Distintos enfoques estratgicos, como poner productos lo antes posible en el mercado, o poner productos de calidad contrastada aunque no sean muy innovadores, o maximizar el beneficio, dan ms peso a un objetivo u otro. As mismo, el entorno externo puede forzar una determinada posicin ante la aparicin de una nueva tecnologa, los avances de la competencia, etc.
EL CICLO DE VIDA.
MANUAL TCNICO PMI - IT Todo proyecto de ingeniera tiene unos fines ligados a la obtencin de un producto, proceso o servicio que es necesario generar a travs de diversas actividades. Algunas de estas actividades pueden agruparse en fases porque globalmente contribuyen a obtener un producto intermedio, necesario para continuar hacia el producto final y facilitar la gestin del proyecto. Al conjunto de las fases empleadas se le denomina ciclo de vida. Sin embargo, la forma de agrupar las actividades, los objetivos de cada fase, los tipos de productos intermedios que se generan, etc. pueden ser muy diferentes dependiendo del tipo de producto o proceso a generar y de las tecnologas empleadas.
Pg. 46 de 200
La complejidad de las relaciones entre las distintas actividades crece exponencialmente con el tamao, con lo que rpidamente se hara inabordable si no fuera por la vieja tctica de divide y vencers. De esta forma la divisin de los proyectos en fases sucesivas es un primer paso para la reduccin de su complejidad, tratndose de escoger las partes de manera que sus relaciones entre s sean lo ms simples posibles. La definicin de un ciclo de vida facilita el control sobre los tiempos en que es necesario aplicar recursos de todo tipo (personal, equipos, suministros, etc.) al proyecto. Si el proyecto incluye subcontratacin de partes a otras organizaciones, el control del trabajo subcontratado se facilita en la medida en que esas partes encajen bien en la estructura de las fases. El control de calidad tambin se ve facilitado si la separacin entre fases se hace corresponder con puntos en los que sta deba verificarse (mediante comprobaciones sobre los productos parciales obtenidos). De la misma forma, la prctica acumulada en el diseo de modelos de ciclo de vida para situaciones muy diversas permite que nos beneficiemos de la experiencia adquirida utilizando el enfoque que mejor de adapte a nuestros requerimientos.
ELEMENTOS DEL CICLO DE VIDA.

Un ciclo de vida para un proyecto se compone de fases sucesivas compuestas por tareas planificables. Segn el modelo de ciclo de vida, la sucesin de fases puede ampliarse con bucles de realimentacin, de manera que lo que conceptualmente se considera una misma fase se pueda ejecutar ms de una vez a lo largo de un proyecto, recibiendo en cada pasada de ejecucin aportaciones de los resultados intermedios que se van produciendo (realimentacin).
Para un adecuado control de la progresin de las fases de un proyecto se hace necesario especificar con suficiente precisin los resultados evaluables, o sea, productos intermedios que deben resultar de las tareas incluidas en cada fase. Normalmente estos productos marcan los hitos entre fases. A continuacin presentamos los distintos elementos que integran un ciclo de vida: Fases. Una fase es un conjunto de actividades relacionadas con un objetivo en el desarrollo del proyecto. Se construye agrupando tareas (actividades elementales) que pueden compartir un tramo determinado del tiempo de vida de un proyecto. La agrupacin temporal de tareas impone requisitos temporales correspondientes a la asignacin de recursos (humanos, financieros o materiales). Cuanto ms grande y complejo sea un proyecto, mayor detalle se necesitar en la definicin de las fases para que el contenido de cada una siga siendo manejable. De esta forma, cada fase de un proyecto puede considerarse un micro-proyecto en s mismo, compuesto por un conjunto de micro-fases. MANUAL TCNICO PMI - IT
Pg. 47 de 200
Otro motivo para descomponer una fase en subfases menores puede ser el inters de separar partes temporales del proyecto que se subcontraten a otras organizaciones, requiriendo distintos procesos de gestin.
Cada fase viene definida por un conjunto de elementos observables externamente, como son las actividades con las que se relaciona, los datos de entrada (resultados de la fase anterior, documentos o productos requeridos para la fase, experiencias de proyectos anteriores), los datos de salida (resultados a utilizar por la fase posterior, experiencia acumulada, pruebas o resultados efectuados) y la estructura interna de la fase. Entregables ("deliverables"). Son los productos intermedios que generan las fases. Pueden ser materiales (componentes, equipos) o inmateriales (documentos, software). Los entregables permiten evaluar la marcha del proyecto mediante comprobaciones de su adecuacin o no a los requisitos funcionales y de condiciones de realizacin previamente establecidos. Cada una de estas evaluaciones puede servir, adems, para la toma de decisiones a lo largo del desarrollo del proyecto. MANUAL TCNICO PMI - IT
TIPOS DE MODELO DE CICLO DE VIDA.

Las principales diferencias entre distintos modelos de ciclo de vida estn en: El alcance del ciclo dependiendo de hasta dnde llegue el proyecto correspondiente. Un proyecto puede comprender un simple estudio de viabilidad del desarrollo de un producto, o su desarrollo completo o, llevando la cosa al extremo, toda la historia del producto con su desarrollo, fabricacin, y modificaciones posteriores hasta su retirada del mercado.
Pg. 48 de 200
Las caractersticas (contenidos) de las fases en que dividen el ciclo. Esto puede depender del propio tema al que se refiere el proyecto (no son lo mismo las tareas que deben realizarse para proyectar un avin que un puente), o de la organizacin (inters de reflejar en la divisin en fases aspectos de la divisin interna o externa del trabajo). La estructura de la sucesin de las fases que puede ser lineal, con prototipado, o en espiral. Vemoslo con ms detalle:
CICLODEVIDALINEAL:
Es el ms utilizado, siempre que es posible, precisamente por ser el ms sencillo. Consiste en descomponer la actividad global del proyecto en fases que se suceden de manera lineal, es decir, cada una se realiza una sola vez, cada una se realiza tras la anterior y antes que la siguiente. Con un ciclo lineal es fcil dividir las tareas entre equipos sucesivos, y prever los tiempos (sumando los de cada fase).
Requiere que la actividad del proyecto pueda descomponerse de manera que una fase no necesite resultados de las siguientes (realimentacin), aunque pueden admitirse ciertos supuestos de realimentacin correctiva. Desde el punto de vista de la gestin (para decisiones de planificacin), requiere tambin que se sepa bien de antemano lo que va a ocurrir en cada fase antes de empezarla.
CICLODEVIDACONPROTOTIPADO:
A menudo ocurre en desarrollos de productos con innovaciones importantes, o cuando se prev la utilizacin de tecnologas nuevas o poco probadas, que las incertidumbres sobre los resultados realmente alcanzables, o las ignorancias sobre el comportamiento de las tecnologas, impiden iniciar un proyecto lineal con especificaciones cerradas. Si no se conoce exactamente cmo desarrollar un determinado producto o cules son las especificaciones de forma precisa, suele recurrirse a definir especificaciones iniciales para hacer un prototipo, o sea, un producto parcial (no hace falta que contenga funciones que se consideren triviales o suficientemente probadas) y provisional (no se va a fabricar realmente para clientes, por lo que tiene menos restricciones de coste y/o prestaciones). Este tipo de procedimiento es muy utilizado en desarrollo avanzado. La experiencia del desarrollo del prototipo y su evaluacin deben permitir la definicin de las especificaciones ms completas y seguras para el producto definitivo.
Pg. 49 de 200
A diferencia del modelo lineal, puede decirse que el ciclo de vida con prototipado repite las fases de definicin, diseo y construccin dos veces: para el prototipo y para el producto real.
CICLODEVIDAENESPIRAL:
El ciclo de vida en espiral puede considerarse como una generalizacin del anterior para los casos en que no basta con una sola evaluacin de un prototipo para asegurar la desaparicin de incertidumbres y/o ignorancias. El propio producto a lo largo de su desarrollo puede as considerarse como una sucesin de prototipos que progresan hasta llegar a alcanzar el estado deseado. En cada ciclo (espirales) las especificaciones del producto se van resolviendo paulatinamente. A menudo la fuente de incertidumbres es el propio cliente, que aunque sepa en trminos generales lo que quiere, no es capaz de definirlo en todos sus aspectos sin ver como unos influyen en otros. En estos casos la evaluacin de los resultados por el cliente no puede esperar a la entrega final y puede ser necesaria repetidas veces.
Pg. 50 de 200
El esquema del ciclo de vida para estos casos puede representarse por un bucle en espiral, donde los cuadrantes son, habitualmente, fases de especificacin, diseo, realizacin y evaluacin (o conceptos y trminos anlogos). En cada vuelta el producto gana en madurez (aproximacin al final deseado) hasta que en una vuelta la evaluacin lo apruebe y el bucle pueda abandonarse.
OBJETIVOS DE CADA FASE.

Dentro de cada fase general de un modelo de ciclo de vida, se pueden establecer una serie de objetivos y tareas que lo caracterizan. Fase de definicin (qu hacer?) Estudio de viabilidad. Conocer los requisitos que debe satisfacer el sistema (funciones y limitaciones de contexto). Asegurar que los requisitos son alcanzables. Formalizar el acuerdo con los usuarios. Realizar una planificacin detallada. Fase de diseo (cmo hacerlo? Soluciones en coste, tiempo y calidad) Identificar soluciones tecnolgicas para cada una de las funciones del sistema. Asignar recursos materiales para cada una de las funciones. Proponer (identificar y seleccionar) subcontratas. Establecer mtodos de validacin del diseo. Ajustar las especificaciones del producto. Fase de construccin Generar el producto o servicio pretendido con el proyecto. Integrar los elementos subcontratados o adquiridos externamente. Validar que el producto obtenido satisface los requisitos de diseo previamente definidos y realizar, si es necesario, los ajustes necesarios en dicho diseo para corregir posibles lagunas, errores o inconsistencias. Fase de mantenimiento y operacin Operacin: asegurar que el uso del proyecto es el pretendido. Mantenimiento (nos referimos a un mantenimiento no habitual, es decir, aquel que no se limita a reparar averas o desgastes habituales - este es el caso del mantenimiento en productos software, ya que en un programa no cabe hablar de averas o de desgaste).
LOS PROYECTOS DE I+D.

En el caso de la investigacin bsica el resultado esperado son conocimientos cientficos. No existe ninguna fase de construccin y s fases que recojan las tareas de experimentacin. En la investigacin aplicada el resultado esperado suele ser alguna tecnologa aplicable para procesos o para productos. Dependiendo del grado de cercana a la aplicacin que llegue a alcanzarse el modelo puede ser bsicamente como el anterior o incluir una fase de aplicacin piloto. En el desarrollo de productos o procesos nuevos o significativamente modificados s aparece ya una fase de construccin, aunque normalmente se tratar de la realizacin de un prototipo. Normalmente el cliente no ser el usuario final, sino los departamentos de ingeniera de produccin de la propia empresa o de otra que contrata el desarrollo. La I+D es costosa por depender de personal muy cualificado, por realizarse de modo generalmente artesanal y por requerir bucles de realimentacin que multiplican, para hacer frente a incidencias, la duracin del proyecto. MANUAL TCNICO PMI - IT
Pg. 51 de 200
IDENTIFICACIN DE ACTIVIDADES.
Larealizacindetodaslasactividadesytareasidentificadases,alavez,requisitonecesarioy suficienteparalograrelresultadofinalqueelproyectopersigue.
Una de las primeras y ms importantes misiones del jefe de proyecto es la identificacin y descripcin de las actividades que es necesario acometer y desarrollar para llegar al resultado adecuado. Antes de iniciar la andadura hay que elegir el camino ms conveniente, el rumbo que se debe seguir y el ritmo a imprimir a cada etapa. Esta tarea implica elegir entre mltiples opciones y resolver un sinfn de incgnitas. Y todo ello hay que hacerlo "a priori", desconociendo lo que ocurrir en la realidad y asumiendo los niveles de complejidad e in habitualidad que son propios de los proyectos. Se trata pues de un trabajo de naturaleza tcnica que slo podr ser realizado por un profesional en la materia, que rena la formacin tcnica necesaria y una suficiente dosis de experiencia. Por ello es necesario que el Jefe de Proyecto posea una elevada competencia profesional en la tecnologa dominante del proyecto, aparte de otras cualidades gerenciales y personales. No obstante, si la dificultad del proyecto lo requiere, el Jefe de Proyecto podr ser en este punto asesorado y aconsejado por otros expertos. En proyectos de gran envergadura puede ser necesario establecer un segundo escaln de jefatura dentro del proyecto, nombrando responsables de subproyectos o de paquetes de actividades o de actividades y tareas. La metodologa siempre es la misma: subdividir el proyecto en partes con entidad propia pero ms dominables que el proyecto global. Si el caso lo justifica, la descripcin de actividades podr hacerse de forma piramidal en varios niveles: subproyectos, paquetes, actividades, tareas. Para la definicin de actividades es necesario contar con los siguientes datos: La Estructura de Desagregacin de Proyecto Especificaciones y objetivos del proyecto Informacin histrica qu actividades fueron necesarias en proyectos similares anteriores Limitaciones presupuesto total, plazo de entrega Hiptesis: se ha de elaborar una lista de actividades que complete todas las actividades requeridas para realizar el proyecto.
En la tarea de descomposicin de actividades, se trata de subdividir los elementos del proyecto en componentes lo suficientemente pequeos para facilitar las tareas de programacin, ejecucin y control. Para ello, ser necesario: Identificar los elementos principales del proyecto, fases y micro fases. Identificar los componentes de dichos elementos Dnde acaba la descomposicin? Cuando se disponga de: entradas y salidas definidas Obtencin de estimaciones adecuadas de duracin y coste. Comprobar la correccin de la descomposicin son los componentes inferiores necesarios y suficientes? Se puede programar y presupuestar cada componente?
Pero la enumeracin de actividades no es suficiente, y ha de ir acompaada de una descripcin concreta que permita comprender su razn de ser, su contenido, el resultado esperable, su responsable y las condiciones de ejecucin. Por ello, es recomendable disponer de alguna ficha o documento que sistematice dichas descripciones y sirva de qua a cuantos deban efectuarlas.
Es lgico que las distintas actividades de un proyecto no se realicen ni de forma sucesiva ni de forma simultnea. Se trata de enlazarlas en el orden ms conveniente posible para resolver adecuadamente los imperativos tcnicos del proyecto y para lograr la combinacin ptima de costes y plazos, obteniendo una lista de precedencias entre actividades. Sin embargo, no todas las actividades en un proyecto tienen que ser secuenciales. Las precedencias pueden ser de tres tipos: Tcnicas (por ejemplo los cimientos antes que la estructura). Pg. 52 de 200
RELACIONES.
Procedimentales: determinadas por la poltica y procedimientos de la organizacin (por ejemplo. el plan de calidad antes que el diseo detallado) Impuestas: por los recursos (por ejemplo vacaciones del personal) por la administracin (por ejemplo el estudio de impacto ambiental antes que la ejecucin de la obra) por el contexto (climatologa, otros proyectos...)
En la labor de secuenciamiento de actividades y establecimiento de sus relaciones suele contarse con el apoyo de tcnicas de planificacin especficas que son comentadas en el apartado de programacin.
ESTIMACIN DE LA DURACIN DE LAS ACTIVIDADES.

Se trata de evaluar el nmero de perodos de trabajo estimados necesarios para completar la actividad. Datos para la estimacin de duraciones Los recursos asignados a la actividad; La capacidad (productividad) de dichos recursos; Informacin histrica proyectos anteriores similares bases de datos comerciales conocimientos y experiencia del equipo de proyecto Tcnicas para la estimacin de duracin de actividades Asesora especializada, basada en experiencia en la gestin de proyectos en el sector. Estimacin por analoga, basada en informacin histrica de duraciones reales de actividades anteriores similares. Simulacin: Clculo de mltiples duraciones basadas en distintas hiptesis. -Monte Carlo: definida una distribucin de probabilidad para cada actividad se calcula la distribucin de probabilidad para el proyecto completo.
LOS RECURSOS.
La asignacin de los recursos suele ser, en la prctica, uno de los aspectos que ms complicaciones produce. La definicin y asignacin de recursos implica de hecho prever tres elementos: qu tipo de recursos se van a usar; en qu cantidad; durante cuanto tiempo.
Y los tres elementos estn estrechamente ligados, puesto que el coste de su aplicacin es el producto naturaleza del recurso x cantidad x tiempo, y, por lo tanto, para mantener el resultado fijo, cualquier variacin de una de las variables implica modificar alguna de las otras dos. La calidad de las estimaciones depende directamente de la capacidad y experiencia del jefe de proyecto y de la mayor o menor familiaridad en realizar ese tipo de proyectos.
PLAZOS Y COSTES.
Una vez que las tareas a realizar han sido identificadas y ordenadas en forma lgica y que se ha determinado qu recursos van a emplearse en cada una de ellas, aparecen con relativa facilidad los costes y plazos previsibles para el conjunto del proyecto. As, lo difcil es saber cuntas horas/hombre u horas/mquina y de qu tipo vamos a emplear. El coste de la unidad de recurso es en general fcil de conocer. Y el coste total de proyecto ser la suma del coste de todas las actividades. MANUAL TCNICO PMI - IT Algo similar ocurre con los plazos: si habamos calculado el plazo de realizacin de cada actividad en funcin de los recursos empleados y hemos establecido el encadenamiento lgico de las actividades, el plazo total del proyecto resultar del camino ms largo que definan las actividades y las relaciones establecidas 8el camino crtico en el grfico PERT). En el apartado programacin aparecen comentadas varias de las tcnicas que se utilizan para calcular estimaciones de plazos, as como el calendario del proyecto.
Pg. 53 de 200
TCNICAS DE PROGRAMACIN.
Las tcnicas de planificacin se ocupan de estructurar las tareas a realizar dentro del proyecto, definiendo la duracin y el orden de ejecucin de las mismas, mientras que las tcnicas de programacin tratan de ordenar las actividades de forma que se puedan identificar las relaciones temporales lgicas entre ellas, determinando el calendario o los instantes de tiempo en que debe realizarse cada una. La programacin debe ser coherente con los objetivos perseguidos y respetar las restricciones existentes (recursos, costes, cargas de trabajo, etc...). La programacin consiste por lo tanto en fijar, de modo aproximado, los instantes de inicio y terminacin de cada actividad. Algunas actividades pueden tener holgura y otras son las actividades crticas (fijas en el tiempo).
PASOS:
Construir un diagrama de tiempos (instantes de comienzo y holgura de las actividades). Establecer los tiempos de cada actividad. Analizar los costes del proyecto y ajustar las holguras (proyecto de coste mnimo).
RESULTADOS:

Disponer de un diagrama de tiempos. Conocer actividades crticas y determinar la necesidad de recursos.
Para comenzar la programacin, se ha de partir de los siguientes datos: Diagrama de red del proyecto (PDM, ADM...); Estimacin de duracin de actividades; Recursos asignados a las actividades; Calendarios de recursos para actividades; Limitaciones, como fechas fijas para resultados o fases del proyecto. Segn los resultados que deseemos conocer, podemos hacer uso de unas determinadas herramientas o de otras. En el siguiente cuadro se muestran todas ellas, que pasamos a comentar a continuacin:
ESCALATEMPORALSDEPENDENCIASNO
DIAGRAMADEGANTT. El diagrama de Gantt es un diagrama de barras desarrollado por Henry Gantt durante la I Guerra Mundial para la programacin del arsenal Frankford. En l se muestran las fechas de comienzo y finalizacin de las actividades y las duraciones estimadas, pero no aparecen dependencias.
Pg. 54 de 200
El grfico de Gantt es la forma habitual de presentar el plan de ejecucin de un proyecto, recogiendo en las filas la relacin de actividades a realizar y en las columnas la escala de tiempos que estamos manejando, mientras la duracin y situacin en el tiempo de cada actividad se representa mediante una lnea dibujada en el lugar correspondiente. La utilidad de un grfico de este tipo es mayor cuando se aaden los recursos y su grado de disponibilidad en los momentos oportunos. Como ventajas tendramos la facilidad de construccin y comprensin, y el mantenimiento de la informacin global del proyecto. Y como desventajas, que no muestra relaciones entre tareas ni la dependencia que existe entre ellas, y que el concepto de % de realizacin es un concepto subjetivo.
GRFICADEHITOS. Un hito es un evento claramente verificable por otra persona y que requiere verificacin antes de poder proseguir con la ejecucin del proyecto. Por ejemplo, la obtencin y formalizacin de los requisitos de usuario constituye un hito en la realizacin de un proyecto de ingeniera software.
La utilidad de los hitos se basa en la buena seleccin de los mismos. Pero al igual que los diagramas de Gantt, la programacin con hitos no aporta o refleja informacin acerca de la interdependencia entre tareas o actividades.
ESCALATEMPORALNODEPENDENCIASS
Un diagrama de red es cualquiera de las representaciones que vinculan las actividades y los eventos de un proyecto entre s para reflejar las interdependencias entre las mismas. Una actividad o evento puede presentar interdependencias con actividades o eventos sucesores, predecesores, o en paralelo. Los ms importantes son:
PERT(PROGRAMEVALUATIONANDREVIEWTECHNIQUE). Desarrollado por la Special Projects Office de la Armada de EE.UU. a finales de los 50s para el programa de I+D que condujo a la construccin de los misiles balsticos Polaris. Est orientada a los sucesos o eventos, y se ha utilizado tpicamente en proyectos de I+D en los que el tiempo de duracin de las actividades es una incertidumbre. Dado que las estimaciones de duracin comportan incertidumbre se estudian las distribuciones de probabilidad de las duraciones. Con un diagrama PERT se obtiene un conocimiento preciso de la secuencia necesaria, o planificada para la ejecucin de cada actividad y utilizacin de diagramas de red. Se trata de un mtodo muy orientado al plazo de ejecucin, con poca consideracin hacia al coste. Se suponen tres duraciones para cada suceso, la optimista a, la pesimista b y la normal m; suponiendo una distribucin beta, la duracin ms probable: t = (a + 4m + b) / 6 .
Pg. 55 de 200
Generalmente se denominan tcnicas PERT al conjunto de modelos abstractos para la programacin y anlisis de proyectos de ingeniera. Estas tcnicas nos ayudan a programar un proyecto con el coste mnimo y la duracin ms adecuada. Estn especialmente difundidas el PERT y el CPM. Aplicacin de las tcnicas PERT: Determinar las actividades necesarias y cuando lo son. Buscar el plazo mnimo de ejecucin del proyecto. Buscar las ligaduras temporales entre actividades del proyecto. Identificar las actividades crticas, es decir, aquellas cuyo retraso en la ejecucin supone un retraso del proyecto completo. Identificar el camino crtico, que es aquel formado por la secuencia de actividades crticas del proyecto. Detectar y cuantificar las holguras de las actividades no crticas, es decir, el tiempo que pueden retrasarse (en su comienzo o finalizacin) sin que el proyecto se vea retrasado por ello. Si se est fuera de tiempo durante la ejecucin del proyecto, seala las actividades que hay que forzar. Nos da un proyecto de coste mnimo.
PDM(PRECEDENCEDIAGRAMMINGMETHOD)
Se basa en la utilizacin de una red en la que figuran las actividades en los nodos y los arcos representan demoras de tiempo entre los puntos (comienzo o fin de nodo) que unen, a la vez que muestran las dependencias. Permiten reflejar distintas relaciones de precedencia entre tareas.
Entre las ventajas encontramos que el mtodo PDM tiene ms flexibilidad que el mtodo PERT ADM para la modelizacin de grandes proyectos, la representacin grfica es ms sencilla y no hay actividades virtuales.
Est orientada a las actividades, y se aplica en la industria de la construccin, en la que de forma habitual el tiempo de cada actividad es muy controlable. Las actividades se representan con flechas que se conectan con nodos para mostrar las dependencias.
ADM(ARROWDIAGRAMMINGMETHOD)
ESCALATEMPORALSDEPENDENCIASS
Diagrama de tiempos con interdependencias Se trata de un grfico de Gantt en el que aparecen las dependencias entre actividades y los recursos implicados en cada una de ellas. Permite de esta forma tener una idea ms real del proyecto que la que obtenamos con el diagrama de Gantt que mostrbamos anteriormente.
Pg. 56 de 200
MTODODELCAMINOCRTICOCPM. Camino crtico

El camino crtico en un proyecto es la sucesin de actividades que dan lugar al mximo tiempo acumulativo. Determina el tiempo ms corto que podemos tardar en hacer el proyecto si se dispone de todos los recursos necesarios. Es necesario conocer la duracin de las actividades. Este concepto es utilizado por dos mtodos: Mtodo del tiempo estimado (CPM) La duracin de una actividad es la ms probable de duracin. Tiempo que se empleara en condiciones normales (m). Situacin determinista. Mtodo del tiempo esperado (PERT) Determinacin probabilstica de los tiempos esperados (Te), en funcin de los siguientes tiempos: Duracin ms corta (a) Duracin ms larga (b) Duracin ms probable (m) (el mismo que en CPM) Duracin esperada: Te = (a + 4m + b) / 6
Clculo del camino crtico

1. Calcular Te m segn el mtodo empleado para cada actividad. Se coloca en el grafo encima o debajo de cada flecha. 2. Calcular las fechas early -fecha mnima de comienzo de la actividad, MIC del suceso anterior- y last - fecha mnima de comienzo de la actividad, MAC del suceso posterior- de las distintas actividades que configuran el proyecto. (Calcular el MIC y el MAC de todos los sucesos del proyecto). 3. Clculo de las holguras. 4. Identificacin del camino crtico.
Holguras
La holgura de una actividad es el margen suplementario de tiempo que tenemos para determinar esa actividad. Las actividades crticas no tiene holgura. Holgura de un suceso Hs: Hs = MAC del suceso MIC del suceso Holgura total de una actividad Ht: Ht = MAC del s.p. MIC del s.a. duracin tarea Margen suplementario de tiempo de esa actividad sin que se altere el MIC de ninguna actividad crtica. Holgura libre de unaHi: HI = MIC del s.p. MIC del s.a. duracin tarea Margen suplementario de tiempo para esa actividad sin que se altere el MIC de cualquier actividad. Holgura independiente Hi: Hi = MIC del s.p. MAC del s.a. duracin tarea Margen suplementario de tiempo que existe en una actividad si las actividades precedentes terminaran lo ms tarde posible, y las actividades posteriores empezaran lo antes posible.
Actividades crticas
Una actividad es crtica cuando no se puede cambiar sus instantes de comienzo y finalizacin sin modificar la duracin total del proyecto. La concatenacin de actividades crticas es el camino crtico. En una actividad crtica la fecha early coincide con la ms tarda de comienzo, y la fecha ms temprana de finalizacin coincide con la fecha last de la actividad. La holgura total es 0.
PROGRAMACINCONRECURSOSLIMITADOSYPROGRAMACINCONCOSTEMNIMO.

Pg. 57 de 200
Programacin con recursos limitados Hasta ahora slo se ha tenido en cuenta el anlisis de relaciones temporales entre las actividades del proyecto. Pero adems, hay que tener en cuenta los recursos, su consumo y sus limitaciones. El proceso, por lo tanto, ante la programacin sera el siguiente: Programacin de duracin mnima sin tener en cuenta los recursos. Se estudia si moviendo las actividades no crticas dentro del margen que representan sus holguras, se puede conseguir el objetivo perseguido en relacin con los recursos. Si no es posible, aplicar alguna de las tcnicas para programar bajo limitacin de recursos.
Minimizacin de costes
Se trata de ajustar las holguras de las actividades, con la premisa de que la duracin total est prefijada por las actividades crticas. Hay costes que disminuyen con el tiempo (costes directos) y costes que aumentan con el tiempo (costes indirectos). Existen dos mtodos: Hacer variaciones en el grafo: hacer actividades en paralelo, con lo que se reducen los costes. Variar los recursos asignados: los costes que representan las actividades son costes directos; si se consigue alargarlas, se reducen sus costes.
Proceso de minimizacin de costes Fase 1: Estimacin de los lmites de duracin y coste de cada actividad Fase 2: Determinacin de la pendiente de coste para cada actividad Fase 3: Alargamiento de todas las tareas no crticas que tengan pendiente de coste negativa Fase 4: Determinacin del intercambio de tiempo-coste ms favorable de las posibles en el camino crtico Fase 5: Tantear, alargando y acortando actividades crticas hasta que las pendientes positivas y negativas resultantes sean iguales.
TOMA DE DECISIONES.
Es el proceso durante el cual la persona debe escoger entre dos o ms alternativas. Todos y cada uno de nosotros pasamos los das y las horas de nuestra vida teniendo que tomar decisiones. Algunas decisiones tienen una importancia relativa en el desarrollo de nuestra vida, mientras otras son gravitantes en ella. Para los administradores, el proceso de toma de decisin es sin duda una de las mayores responsabilidades. La toma de decisiones en una organizacin se circunscribe a una serie de personas que estn apoyando el mismo proyecto. Debemos empezar por hacer una seleccin de decisiones, y esta seleccin es una de las tareas de gran trascendencia. Con frecuencia se dice que las decisiones son algo as como el motor de los negocios y en efecto, de la adecuada seleccin de alternativas depende en gran parte el xito de cualquier organizacin.
Unadecisinpuedevariarentrascendenciayconnotacin.
Los administradores consideran a veces la toma de decisiones como su trabajo principal, porque constantemente tienen que decidir lo que debe hacerse, quin ha de hacerlo, cundo y dnde, y en ocasiones hasta cmo se har. Sin embargo, la toma de decisiones slo es un paso de la planeacin, incluso cuando se hace con rapidez y dedicndole poca atencin o cuando influye sobre la accin slo durante unos minutos.
LAPENETRACINDELATOMADEDECISIONES.
La toma de decisiones en una organizacin invade cuatro funciones administrativas que son: Planeacin, Organizacin, Direccin y Control. Funciones administrativa dentro de la organizacin al tomar decisiones: LA PLANEACIN: Seleccin de misiones y objetivos as como de las acciones para cumplirlas. Esto implica Toma de decisin. Cules son los objetivos de la organizacin, a largo plazo? Qu estrategias son mejores para lograr este objetivo? Cules deben ser los objetivos a corto plazo? Cun altas deben ser las metas individuales? LAORGANIZACIN: Establecimiento de la estructura que desempean los individuos dentro de la organizacin. Cunta centralizacin debe existir en la organizacin? Cmo deben disearse los puestos? Quin est mejor calificado para ocupar un puesto vacante? Cristian Bailey Consultor IT Pg. 58 de 200
Cundo debe una organizacin instrumentar una estructura diferente? LADIRECCIN: Esta funcin requiere que los administradores influyan en los individuos para el cumplimiento de las metas organizacionales y grupales. Cmo manejo a un grupo de trabajadores que parecen tener una motivacin baja? Cul es el estilo de liderazgo ms eficaz para una situacin dada? Cmo afectar un cambio especfico a la productividad del trabajador? Cundo es adecuado estimular el conflicto? ELCONTROL: Es la medicin y correccin del desempeo individual y organizacional de manera tal que se puedan lograr los planes. Qu actividades en la organizacin necesitan ser controladas? Cmo deben controlarse estas actividades? Cundo es significativa una desviacin en el desempeo? Cundo la organizacin est desempendose de manera efectiva?
RACIONALIDAD.
Anlisis que requiere de una meta y una comprensin clara de las alternativas mediante las que se puede alcanzar una meta, un anlisis y evaluacin de las alternativas en trmino de la meta deseada, la informacin necesaria y el deseo de optimizar. A qu nos referimos cundo hablamos de la racionalidad en la toma de decisiones? Cuando un administrador se enfrenta a una toma de decisin, adems de comprender la situacin que se presenta, debe tener la capacidad de analizar, evaluar, reunir alternativas, considerar las variables, es decir, aplicar estas tcnicas para encontrar soluciones razonables; podemos decir entonces, que se trata de una toma de decisin basada en la racionalidad. RACIONALIDADLIMITADAOCIRCUNSCRITA Accin racional limitada debido a la falta de informacin, de tiempo o de la capacidad para analizar alternativas a la luz de las metas buscadas; metas confusas; la tendencia humana a no correr riesgos al tomar una decisin. HEBERT SIMON, ha llamado a esto SATISFACCIN SUFICIENTE, es decir, escoger un curso de accin que sea satisfactorio o lo bastante bueno, dadas las circunstancias. Aunque muchas decisiones administrativas se toman con el deseo de salir adelante en una forma tan segura como sea posible, la mayora de los administradores intentan tomar las mejores decisiones que puedan, dentro de los lmites de la racionalidad y de acuerdo con el tamao y la naturaleza de los riesgos implcitos.
PROCESORACIONALDETOMADEDECISIONES.
De los procesos existentes para la toma de decisiones, este es catalogado como el proceso ideal. En su desarrollo, el administrador debe: 1.- Determinar la necesidad de una decisin. El proceso de toma de decisiones comienza con el reconocimiento de que se necesita tomar una decisin. Ese reconocimiento lo genera la existencia de un problema o una disparidad entre cierto estado deseado y la condicin real del momento.
3.- Asignar peso a los criterios.
Pg. 59 de 200
2.- Identificar los criterios de decisin. Una vez determinada la necesidad de tomar una decisin, se deben identificar los criterios que sean importantes para la misma. Vamos a considerar un ejemplo: Una persona piensa adquirir un automvil. Los criterios de decisin de un comprador tpico sern: precio, modelo, dos o ms puertas, tamao, nacional o importado, equipo opcional, color, etc. Estos criterios reflejan lo que el comprador piensa que es relevante. Existen personas para quienes es irrelevante que sea nuevo o usado; lo importante es que cumpla sus expectativas de marca, tamao, imagen, etc., y que se encuentre dentro del presupuesto del que disponen. Para el otro comprador lo realmente importante es que sea nuevo, despreciando el tamao, marca, prestigio, etc."
Los criterios enumerados en el paso previo no tienen igual importancia. Es necesario ponderar cada uno de ellos y priorizar su importancia en la decisin. Cuando el comprador del automvil se pone a ponderar los criterios, da prioridad a los que por su importancia condicionan completamente la decisin: precio y tamao. Si el vehculo elegido tiene los dems criterios (color, puertas, equipo opcional, etc.), pero sobrepasa el importe de lo que dispone para su adquisicin, o es de menor tamao al que precisa, entonces nos encontramos con que los dems criterios son secundarios en base a otros de importancia trascendental. 4.- Desarrollar todas las alternativas. Desplegar las alternativas. La persona que debe tomar una decisin tiene que elaborar una lista de todas las alternativas disponibles para la solucin de un determinado problema. 5.- Evaluar las alternativas. La evaluacin de cada alternativa se hace analizndola con respecto al criterio ponderado. Una vez identificadas las alternativas, el tomador de decisiones tiene que evaluar de manera crtica cada una de ellas. Las ventajas y desventajas de cada alternativa resultan evidentes cuando son comparadas. 6.- Seleccionar la mejor alternativa. Una vez seleccionada la mejor alternativa se lleg al final del proceso de toma de decisiones. En el proceso racional, esta seleccin es bastante simple. El tomador de decisiones slo tiene que escoger la alternativa que tuvo la calificacin ms alta en el paso nmero cinco. El paso seis tiene varios supuestos, es importante entenderlos para poder determinar la exactitud con que este proceso describe el proceso real de toma de decisiones administrativas en las organizaciones. El tomador de decisiones debe ser totalmente objetivo y lgico a la hora de tomarlas. Tiene que tener una meta clara y todas las acciones en el proceso de toma de decisiones llevan de manera consistente a la seleccin de aquella alternativa que maximizar la meta. Vamos a analizar las tomas de decisiones de una forma totalmente racional: Orientada a un objetivo.- Cuando se deben tomar decisiones, no deben existir conflictos acerca del objetivo final. El lograr los fines es lo que motiva que tengamos que decidir la solucin que ms se ajusta a las necesidades concretas. Todas las opciones son conocidas.- El tomador de decisiones tiene que conocer las posibles consecuencias de su determinacin. As mismo tiene claros todos los criterios y puede enumerar todas las alternativas posibles. Las preferencias son claras.- Se supone que se pueden asignar valores numricos y establecer un orden de preferencia para todos los criterios y alternativas posibles. El lder del grupo desempea un importante papel en la aplicacin de este mtodo. De hecho, slo l conoce la naturaleza especfica del problema. Su funcin consiste en estrechar y dirigir cuidadosamente la discusin sin revelar el problema de que se trata. El principal motivo de ello es impedir que el grupo llegue a una solucin prematura. Este sistema supone una compleja serie de interacciones para el surgimiento de una solucin, frecuentemente la invencin de un nuevo producto. Etapas De La Toma De Decisin Identificacin y diagnostico del problema Generacin de soluciones alternativas Seleccin de la mejor alternativa Evaluacin de alternativas Evaluacin de la decisin Implantacin de la decisin Identificacinydiagnsticodelproblema: Reconocemos en la fase inicial el problema que deseamos solucionar, teniendo en cuenta el estado actual con respecto al estado deseado. Una vez que el problema es identificado se debe realizar el diagnstico y luego de esto podremos desarrollar las medidas correctivas.
Pg. 60 de 200
Generacindesolucionesalternativas: La solucin de los problemas puede lograrse por varios caminos y no slo seleccionar entre dos alternativas, se pueden formular hiptesis ya que con la alternativa hay incertidumbres. Evaluacindealternativas: La tercera etapa implica la determinacin del valor o la adecuacin de las alternativas que se generaron. Cul solucin ser la mejor?. Los gerentes deben considerar distintos tipos de consecuencia. Por supuesto que deben intentar predecir los efectos sobre las medidas financieras u otras medidas de desarrollo. Pero tambin existen otras consecuencias menos definidas que hay que atender. Las decisiones establecen un precedente y hay que determinar si este ser una ayuda o un obstculo en el futuro. Por supuesto, no es posible predecir los resultados con toda precisin. Entonces pueden generar planes de contingencia, esto es, curso alternativo de accin que se pueden implantar con base en el desarrollo de los acontecimientos. Seleccindelamejoralternativa: Cuando el administrador ha considerado las posibles consecuencias de sus opciones, ya est en condiciones de tomar la decisin. Debe considerar tres trminos muy importantes. Estos son: maximizar, satisfacer y optimizar. Maximizar: es tomar la mejor decisin posible Satisfacer: es la eleccin de la primera opcin que sea mnimamente aceptable o adecuada, y de esta forma se satisface una meta o criterio buscado. Optimizar: Es el mejor equilibrio posible entre distintas metas. Implementacindeladecisin: El proceso no finaliza cuando la decisin se toma; esta debe ser implementada. Bien puede ser que quienes participen en la eleccin de una decisin sean quienes procedan a implementarla, como en otras ocasiones delegan dicha responsabilidad en otras personas. Debe existir la comprensin total sobre la eleccin de la toma de decisin en s, las razones que la motivan y sobre todo debe existir el compromiso de su implementacin exitosa. Para tal fin, las personas que participan en esta fase del proceso, deberan estar involucradas desde las primeras etapas que anteriormente hemos mencionado. A continuacin citaremos los pasos que los gerentes deben considerar durante la planeacin de su ejecucin: Determinar cmo se vern las cosas una vez que la decisin est funcionando completamente. Orden cronolgico (de ser posible con un diagrama de flujo) de los pasos para lograr una decisin totalmente operativa. Considerar recursos disponibles y actividades necesarias para poner cada paso en prctica. Considerar el tiempo que tomar cada una de las etapas. Asignacin de responsabilidades a personas especficas para cada etapa. Podemos estar seguros de que cuando una toma de decisin es tomada, sta probablemente generar ciertos problemas durante su ejecucin, por lo tanto los gerente deben dedicar el tiempo suficiente al reconocimiento de los inconvenientes que se pueden presentar as como tambin ver la oportunidad potencial que estos pueden representar. De esta manera, podramos decir que es fundamental que los gerentes se pregunten: Qu problemas podra causar esta accin, y qu podramos hacer para impedirlo? Qu beneficios u oportunidades no intencionales podran surgir? Cmo podremos asegurarnos de que sucedan? Cmo podemos estar preparados para actuar cuando se presenten las oportunidades? Evaluacindeladecisin: Evaluar la decisin, forma parte de la etapa final de este proceso. Se recopila toda la informacin que nos indique la forma como funciona una decisin, es decir, es un proceso de retroalimentacin que podra ser positiva o negativa. Si la retroalimentacin es positiva, pues entonces nos indica que podemos continuar sin problemas y que incluso se podra aplicar la misma decisin a otras reas de la organizacin. Si por el contrario, la retroalimentacin es negativa, podra ser que: Cristian Bailey Consultor IT Pg. 61 de 200
1) tal vez la implementacin requiera de ms tiempo, recursos, esfuerzos o pensamiento o 2) nos puede indicar que la decisin fue equivocada, para lo cual debemos volver al principio del proceso (re)definicin del problema. Si esto ocurriera, sin duda tendramos ms informacin y probablemente sugerencias que nos ayudaran a evitar los errores cometidos en el primer intento. TiposDeDecisiones Las decisiones, pueden estar divididas en dos categoras. a) DecisinProgramada: Son programadas en la medida que son repetitivas y rutinarias, as mismo en la medida que se ha desarrollado un mtodo definitivo para poder manejarlas. Al estar el problema bien estructurado, el mando no tiene necesidad de pasar por el trabajo y gasto de realizar un proceso completo de decisin. Estas decisiones programadas cuentan con unas guas o procedimientos (pasos secuenciales para resolver un problema) , unas reglas que garanticen consistencias en las disciplinas y con un alto nivel de justicia , aparte de una poltica, que son las directrices para canalizar el pensamiento del mando en una direccin concreta. b) DecisinnoProgramada: La reestructuracin de una organizacin o cerrar una divisin no rentable, son ejemplos de decisiones no programadas, Tambin la creacin de una estrategia de mercado para un nuevo producto.
IMPORTANCIADELATOMADEDECISIONESENGRUPO. Si bien el supervisor casi siempre toma las decisiones solo, hay ocasiones en que debe aprovechar la ventaja de contar con su grupo de subordinados para tomar ciertas decisiones.
La toma de decisiones en las organizaciones modernas son realizadas en grupo o comits de trabajo, quedan individualizadas en el momento en que las mismas pasan a formar parte de las bien estructuradas o estndar. Estas decisiones individuales o grupales tienen cada una de ellas sus ventajas y desventajas, que influyen de manera determinante en el rol de la gerencia de nuestras organizaciones. Vamos analizar las ventajas y desventajas del trabajo en grupo o comits: Ventajas: 1. Informacin y conocimiento ms completos: Lgicamente un grupo logra recopilar ms informacin, teniendo acceso a ms fuentes informativas que un solo individuo, independiente de la educacin y de la experiencia de este. Por lo tanto los grupos pueden ofrecer mayores aportes, tanto en la cantidad como en la diversidad para la Toma de decisiones. 2. Incrementar la aceptacin de una solucin o bien la variedad de puntos de vista: Muchas decisiones fracasan despus de elegida una opinin, debido a que un sector de gente no la acepta como una solucin posible, cada uno de sus integrantes tiene un punto de vista propio que difiere, en cierta medida, del de los dems, como resultado, la cantidad y tipos de opciones son mayores que los del individuo que trabaja solo. La participacin en grupo facilita una amplia discusin y una aceptacin ms participativa, es posible que haya divergencias en los acuerdos, pero se plantea y permite su discusin para cuando ya sea aceptada, sea un compromiso de todo un conjunto. Es difcil que los asistentes al grupo de discusin ataquen o dificulten una decisin que ellos ayudaron a desarrollar. Las decisiones grupales incrementan la aceptacin de la solucin final y facilitan su instrumentacin. Incrementan la Legitimidad: Los mtodos democrticos son aceptados por todos los componentes de la sociedad. Cuando el proceso es grupal, intervienen todos los aditamentos de los ideales democrticos. Si el tomador de decisiones no consulta a otros antes de tomar una de ellas, el hecho del poder que tiene no le exime de quedar como una persona autoritaria y arbitraria. Las decisiones grupales no tienen la varita mgica de la perfeccin, pero sin lugar a dudas son las menos peligrosas y por lo tanto las que tienen un menor nivel de error. Reduccin de los problemas de comunicacin: Puesto que el grupo participa en la toma de decisin, todos sus integrantes estn conscientes de la situacin, por lo general la puesta en marcha de la Pg. 62 de 200
3.
4.
solucin se realiza sin tropiezos. Las preguntas, las objeciones y los obstculos a los que normalmente se enfrenta la implantacin de una decisin, con frecuencia desaparecen, cuando esta ltima es resultado de la participacin del grupo. Desventajas: 1. Requieren mucho tiempo: El reunir al grupo toma su tiempo, pero con una buena organizacin, las reuniones estarn programadas de antemano en un espacio de tiempo oportuno (vara de acuerdo a la organizacin y no debe ser menor de dos semanas). El resultado es que los grupos consumen ms tiempo en alcanzar una decisin a diferencia de un solo individuo. 2. Presiones de aceptacin: Si bien se supone que todos los miembros del grupo deben sentirse libre para expresar sus opiniones, sugerencias y recomendaciones, no deja de ser cierto que a veces existe cierta presin para que todo el mundo se rena y acate el consenso general, llamado con frecuencia Pensamiento grupal. Esta presin puede provocar que el grupo pase por alto un consejo o sugerencia positiva de algunos de los presentes. Se presiona a los inconformes para que se ajusten y adhieran a la opinin de la mayora. En los grupos existen presiones sociales. El deseo de los miembros del grupo de ser aceptados y por lo tanto ser protagonistas, puede resultar en un intercambio de pareceres condicionado a deseos de una demostracin de un liderazgo. Finalmente se llegar a un mismo resultado que necesariamente debe ser aceptado por todos para tener validez. Responsabilidad ambigua: Los miembros de un grupo tienen que compartir la responsabilidad, por lo tanto la individualidad se diluye, dndole un gran valor a los resultados. El Compromiso: En ciertas ocasiones el grupo se estanca y se muestra incapaz de llegar a un acuerdo sobre qu soluciones recomendar. Obligados a tomar una decisin, se alienta a los miembros a llegar a un compromiso o a darse por vencidos, aceptando una versin diferente de su solucin. Este inconveniente es muy usual cuando el grupo se subdivide en grupos ms pequeos, cada uno de los cuales apoya una solucin diferente.
3. 4.
COMOLOGRARQUEFUNCIONELATOMADEDECISIONESENGRUPO:
La toma de decisiones en grupo puede utilizarse con mucha eficiencia si el supervisor maneja la situacin como debe ser. Uno de los factores ms importantes consiste en ganarse el apoyo de los miembros del grupo; sealndoles el valor de sus aportes en la solucin del problema. Un segundo enfoque muy til consiste en dar a cada integrante del grupo elementos especficos en que pensar y trabajar, para que pueda reconocer sus aportes; tambin crear un entorno donde las personas puedan expresarse abierta y francamente y que estimule tanto los aportes creativos como las discusiones sobre las fallas o los errores en que podra incurrirse. Esto ltimo es de especial importancia para evitar el surgimiento del Pensamiento Grupal.
LA GERENCIA DEBE TOMAR DECISIONES DIFCILES Y ESO HACE IMPOSIBLE HACER FELICES ATODOS:
Momentos como ste agregan nuevas tensiones y demandas a todos en la empresa. La gerencia tiene que tomar decisiones difciles y medidas poco populares. Esto no es nada fcil ni agradable. Adems, eso no demuestra que la gerencia sea vil e insensible. Observar a una gran empresa pasar por una gran transicin y cambio es como observar a los participantes de un juego de cartas. Algunos ganan, algunos pierden y otros empatan. Como el repartidor de cartas, la gerencia debe trabajar para el bien de la organizacin, asumiendo que en el proceso, algunas personas sern ms golpeadas que otras. Si usted fuera la persona a cargo enfrentara el mismo dilema. MANUAL TCNICO PMI - IT Es fcil sentarse a criticar la manera en que la alta gerencia hace las cosas. Tambin es fcil acusar a la gerencia de no preocuparse por la gente. Cuando a uno no le gusta lo que est sucediendo, la tendencia natural es buscar a alguien a quien culpar. Pero en lugar de sealar a sus superiores, considere la posibilidad de que ellos slo estn haciendo lo que deben hacer. Es muy comn preocuparse profundamente por los dems, y an as, no
poderles dar todo lo que quieren.
Pg. 63 de 200
GESTIN DE LOS RECURSOS RRHH.

Lagestinexitosadeproyectos,independientementedelaestructuraorganizativa,esslotan buenacomoloseanlosindividuosylderesquegestionenlasfuncionesbsicas. Cuando hablamos de Gestin de Recursos Humanos nos estamos refiriendo a la gestin de las personas que conforman la organizacin; y estamos, en este caso, hablando de la gestin del principal recurso del que disponen las organizaciones para mantener y mejorar su competitividad. Por qu esta importancia, cada vez mayor, al recurso humano? Nos encontramos en un ambiente en el que las tecnologas, los mercados, los productos... cambian muy rpidamente; en un ambiente en el que la innovacin y la actividad centrada en el cliente son dos de las principales armas estratgicas de que disponen las empresas. Y son las personas que conforman la organizacin las que van a innovar y las que van a conseguir que los clientes estn o no satisfechos. En el rea de la gestin de proyectos, la gestin de recursos humanos es un elemento fundamental. La creacin del equipo de trabajo es bsico para que el proyecto se pueda realizar bien. La figura ms importante la representa el Director de Proyecto, ya que su estilo de direccin y la forma de resolver los conflictos influye de manera decisiva en la marcha del proyecto. A l dedicamos un apartado especial. En esta seccin presentamos las siguientes divisiones: El equipo de trabajo. Cmo se constituye, quienes lo integran, caractersticas. Perfiles tpicos de los integrantes. Director tcnico del proyecto, organizacin del equipo. Conflictos. Causas, cmo resolverlos.
PERFILES DE UN EQUIPO DE TRABAJO.

Un perfil es una caracterizacin genrica de un tipo de actividad ligado a las necesidades de una organizacin. No todos los perfiles son necesarios durante todo el proyecto ni en todos los proyectos. En funcin del ciclo de vida empleado y de las actividades a realizar, se pueden determinar a priori los perfiles requeridos. En la definicin de un perfil, intervienen los siguientes aspectos: Conocimientos generales requeridos. Conocimientos tcnicos especializados requeridos. Habilidades de comunicacin requeridas. Actitudes requeridas en el trabajo. Relacin con otros perfiles. Recursos materiales asociados al perfil. Caractersticas temporales. A partir de esa informacin es posible conocer las personas requeridas y asignar responsabilidades individuales a cada una de ellas. No obstante, no debe confundirse esta definicin con las actitudes deseadas en una determinada persona. Recurdese que no siempre hay una relacin biunvoca. Extrapolando las caractersticas comunes de la mayor parte de proyectos, podemos establecer una relacin de perfiles tpicos, como la que se muestra a continuacin: Documentalistas. Diseadores. Analistas. Probadores. Implementadores. Vendedores. Director de Proyecto. Psiclogos. Controladores de tiempos. Administrativos.
Pg. 64 de 200
Es necesario hacer ciertos comentarios a alguna de las actividades expuestas. En primer lugar, todos los proyectos de ingeniera poseen la funcin de documentacin como una de las ms importantes. Tngase en cuenta que, en muchos casos, el proyecto slo genera documentacin durante las primeras fases del ciclo de vida. Esta funcin puede estar distribuida entre todos los componentes del equipo de trabajo y la responsabilidad de la misma recaer en los responsables de cada una de las fases y, en ltima instancia, en el Director de Proyecto. Desde luego, el contenido de la documentacin siempre la tiene que generar la persona o personas a cargo de una determinada tarea. Este enfoque tiene como consecuencia negativa la necesidad de integrar toda la documentacin generada por diversas personas en diferentes momentos de acuerdo con unos formatos preestablecidos y dificulta el control de la misma. Como contrapartida, es posible generar un perfil especfico como documentador con la responsabilidad, no de generar el contenido especfico de la documentacin que haya que generar, sino del almacenamiento, control, integracin, generacin de documentos concretos para diversos fines (e idiomas) y homogeneizacin de la misma. Otro perfil importante y bsico de un equipo de trabajo en un proyecto de ingeniera es el de diseador. Existen distintos niveles a los que se desarrolla esta actividad (arquitecto, analista, funcional, a alto nivel, etc.) e incluso en proyectos grandes y complejos puede ser necesario distinguir un papel especial como Director Tcnico del Proyecto (no confundir esta figura con la de Director Tcnico de una organizacin que no tiene por qu estar ligada a un proyecto concreto sino a todas las actividades de carcter tcnico que se hagan en la empresa, como la gestin del recurso tecnolgico). El Director Tcnico tiene las siguientes funciones: 1. Determinar las caractersticas tcnicas del producto o proceso objeto del proyecto. 2. Tomar las decisiones relativas a las soluciones tcnicas a emplear. 3. Determinar las tecnologas requeridas y responsabilizarse de su identificacin, evaluacin o seleccin en caso de no disponer de ellas. 4. Responsabilizarse de la formacin tcnica del equipo de trabajo (en coordinacin con otras unidades funcionales de carcter horizontal de la empresa). En proyectos pequeos esta figura se solapa con la de Director de Proyecto. Junto con ste ltimo y, en muchas ocasiones, el Director administrativo (costes, compras, personal, etc.), constituyen el equipo de direccin del proyecto.
ORGANIZACIN MATRICIAL DEL EQUIPO DE PROYECTO. RELACIN JEFE DE PROYECTO JEFEUNIDADFUNCIONAL:

Como se ha comentado, una de las funciones ms relevantes de la direccin de proyectos es la de integrar en el equipo de proyecto a especialistas procedentes de otras reas o de otras empresas, responsabilidad que debe ser asumida por el jefe de proyecto. La mayor dificultad deriva de que se rompe uno de los principios de gestin clsicos, como es el principio de unidad de direccin. Es decir, un empleado de una unidad funcional que es asignado temporalmente a un proyecto pasa a tener dos jefes: su jefe jerrquico de la unidad funcional, del cual depende formal y habitualmente, y el jefe de proyecto, a las rdenes del cual trabaja slo en el mbito del proyecto.
Ambos jefes deben colaborar en ciertos aspectos del proyecto, y en particular en el nombramiento de los diferentes tcnicos que intervendrn en el proyecto. Si el director funcional es el que posee los recursos y conoce la vala personal y forma de trabajar de los mismos, es evidente que ser la persona ms adecuada para proporcionar las personas que intervendrn en el proyecto. Pero si el jefe de proyecto ha de conseguir sus objetivos poniendo en juego los recursos aportados al proyecto, deber velar porque esos recursos sean idneos en calidad y cantidad, no pudiendo en caso contrario responsabilizarse de la consecucin de los objetivos. A continuacin representamos un diagrama con la organizacin matricial de un proyecto donde queda reflejada esta interdependencia entre los recursos asignados y las unidades funcionales. MANUAL TCNICO PMI - IT
Pg. 65 de 200
JEFE DE PROYECTO -- LA GERENCIA DE PROYECTOS.

El Jefe de Proyecto se destaca como la figura clave en la planificacin, ejecucin y control del proyecto y es el motor que ha de impulsar el avance del mismo mediante la toma de decisiones tendentes a la consecucin de los objetivos. El Jefe de Proyecto es un verdadero jefe, es decir, tiene poder ejecutivo y autoridad para mandar y tomar decisiones dentro del mbito y objetivos del proyecto. No es un mero coordinador o animador, como en algunas ocasiones se piensa. De la misma forma, tampoco sera correcto pensar que el Jefe de Proyecto tiene un poder absoluto y dictatorial sobre el mismo, ya que se encuentra inmerso en la estructura y organizacin de la empresa. Las relaciones bsicas del Director de Proyecto con otras unidades o personas dependen, en gran medida, de la estructura organizativa que posea la organizacin. A continuacin se muestra el caso de una empresa que sigue una estructura orientada a proyectos, donde se observa la importancia del Director de Proyecto.
Pg. 66 de 200
Es necesario hacer mencin a una caracterstica importante como es el carcter transitorio de todo proyecto, lo que hace que la misin de un Jefe de Proyecto tenga la misma naturaleza temporal. Al trmino de un proyecto, el Jefe del mismo puede pasar a dirigir otro o a formar parte de su equipo, pero tambin puede pasar a desarrollar alguna actividad de tipo permanente dentro de la organizacin. Facilitar esa integracin a la estructura habitual debe ser una tarea no despreciada por la empresa, evitando as el "hacer pasillos" al que se ven sometidos muchos directores de proyecto entre una operacin y otra.
DEQUSEOCUPA:
La misin del Director de Proyecto podra resumirse en: dirigir el equipo de que dispone para alcanzar los objetivos del proyecto. Ms concretamente, podemos destacar las siguientes funciones especficas: Colaboracin con el cliente en la definicin y concrecin de los objetivos del proyecto. Planificacin del proyecto en todos sus aspectos, identificando las actividades a realizar, los recursos a poner en juego, los plazos y los costes previstos. Direccin y coordinacin de todos los recursos empleados en el proyecto. Mantenimiento permanente de las relaciones externas del proyecto: clientes, proveedores, subcontratistas, otras direcciones, etc. Toma de decisiones necesarias para conocer en todo momento la situacin en relacin con los objetivos establecidos. Adopcin de las medidas correctoras pertinentes para poner remedio a las desviaciones que se hubieran detectado. Responder ante clientes y superiores de la consecucin de los objetivos del proyecto. Proponer, en su caso, modificaciones a los lmites u objetivos bsicos del proyecto cuando concurran circunstancias que as lo aconsejen. Esta definicin de funciones no puede considerarse exhaustiva. En cada entidad sera necesario hacer una definicin de funciones ms concreta y adaptada a las caractersticas particulares de cada proyecto.
ELPERFILDEUNJEFEDEPROYECTO:
El Jefe de Proyecto debe tener una perspectiva mucho ms amplia que el conocimiento de las implicaciones tcnicas relativas al proyecto. Se trata de un gestor que necesita un triple perfil: A. TCNICO: El dominio de la tecnologa principal del proyecto es el punto de partida necesario para que el Jefe de Proyecto pueda comprender los puntos clave del mismo, planificar los recursos, generar ideas y soluciones eficaces, controlar la calidad, etc. B. GESTOR: Pero el Jefe de Proyecto tambin debe poseer una notable aptitud gestora, pues no slo se encarga de una dimensin tcnica, sino que debe controlar y conseguir todos los objetivos del proyecto, incluyendo los financieros y de plazo, que suelen ser los ms crticos y ms frecuentemente incumplidos. C. RELACIONES PERSONALES: El Jefe de Proyecto debe poseer una capacidad destacada para las relaciones personales, puesto por un lado, es el representante principal del proyecto ante clientes, proveedores, subcontratistas, otras direcciones funcionales, la propia empresa..., y por otro, debe dirigir a un conjunto de personas sobre los que normalmente no tiene poder jerrquico, y por lo tanto, es necesario hacerlo con grandes dosis de autoridad personal, tacto, habilidad y capacidad de conviccin. La habilidad de un Jefe de Proyecto para ganar el apoyo de otros depende de su manera de dirigir. Si bien el estilo de influencia se compone de una parte de autoridad personal y una poltica de recompensas o castigos, el Jefe de Proyecto no tiene capacidad directa de influir sobre las segundas (s podrn hacerlo indirectamente a travs de informes formales o informales) pues son competencia de los responsables funcionales. A continuacin se muestra una relacin donde se identifican nueve bases de influencia sobre el estilo directivo, datos1 recogidos durante una serie de seminarios sobre direccin de proyectos. Estn ordenados en orden de mayor a menor importancia para los propios directivos: Cristian Bailey Consultor IT Pg. 67 de 200 MANUAL TCNICO PMI - IT
ESTILODIRECTIVOS:
Conocimiento: Capacidad para ganar apoyo, debido a que el personal del proyecto posee una experiencia o conocimiento especiales; es decir, se considera que posee conocimientos que ellos estiman importantes. Autoridad: Capacidad para ganar apoyo, debido a que el personal del proyecto percibe que el jefe de proyecto tiene poder para dar rdenes. Desafodeltrabajo: Capacidad para ganar apoyo, basado en el disfrute personal mientras se realiza un tipo particular de trabajo; orientado a la motivacin intrnseca del personal. Amistad: Capacidad para ganar apoyo, debido a que el personal del proyecto se siente atrado personalmente hacia el jefe de proyecto, al proyecto o ambos. Este poder de la amistad o poder referente y el de conocimiento, a diferencia del de autoridad, no es otorgado por la Direccin de la organizacin, sino que se gana a travs de su relacin con los integrantes del equipo. Asignacin de futuras tareas: Capacidad para ganar apoyo, debido a que el personal percibe que el jefe de proyecto es capaz de influir en la asignacin de sus tareas futuras. Distribucinderecursos: Capacidad para ganar apoyo, debido a que el personal percibe que el jefe de proyecto tiene el poder de asignar recursos financieros (presupuesto). Promocin: Capacidad para ganar apoyo, debido a que el personal del proyecto piensa que el jefe de proyecto puede otorgar recompensas organizativas. Salario: Capacidad para ganar apoyo, debido a que el personal del proyecto percibe al jefe de proyecto como capaz de dispensar directamente recompensas econmicas. Penalizacin: Capacidad para ganar apoyo, debido a que el personal siente que el jefe de proyecto puede aplicar penalizaciones que desean evitar. El poder basado en penalizacin est inexorablemente unido al poder basado en recompensa, siendo uno una condicin necesaria para el otro. Existe una estrecha relacin entre el estilo de influencia y el estilo de resolucin de conflictos, encontrando que ciertos modos de influencia tienden a usarse junto con ciertos modos de resolucin de conflictos. De esta forma, resultados al respecto indican que los jefes de proyecto que ponen nfasis en sus conocimientos y en el reto del trabajo como bases de influencia, tienden a resolver los conflictos por confrontacin y a evitar la retirada, lo que parece lgico puesto que cuanto ms experto es un jefe de proyecto, ms capacidad tiene para evaluar y cuestionar el progreso y la calidad del trabajo. Por otro lado, aquellos jefes de proyecto que se basan en la amistad para obtener una mejor colaboracin con los subordinados, tienden ms a los modos de resolucin de conflictos de compromiso, conciliacin y retirada. Si se relaciona el estilo de influencia del jefe de proyecto, los modos que utiliza para resolver los conflictos y el nivel de resultado global del proyecto, se llega a cuatro conclusiones globales en relacin con las prcticas reales de direccin. 1. Parece que los jefes de proyecto no adoptan un estilo de direccin que minimice la conflictividad globaldesusproyectos. Las bases de influencia que los jefes de proyecto piensan que son ms importantes, como experiencia, autoridad y reto en el trabajo, no estn asociadas a menores grados de conflicto que las dems. Es decir, en proyectos complejos los conflictos son inevitables, y la buena realizacin de los trabajos depende a menudo del acierto con que el jefe de proyecto pueda resolver una cantidad de cuestiones conflictivas delicadas , sin poner en peligro el calendario acordado, el presupuesto o los parmetros acordados. 2. La eficacia de los modos de resolucin de conflictos est determinada en gran medida por la situacin. A menudo, la conflictividad sobre diferentes cuestiones, como fechas, prioridades o recursos humanos, se origina debido a las interacciones del jefe de proyecto con diferentes elementos de la empresa. Por ello, gestionar diversas situaciones de conflicto requiere por su parte un alto grado de adaptabilidad a diferentes situaciones para encontrar el modo ms apropiado de resolucin de los conflictos. 3. Los jefes de proyecto presentan generalmente mayor flexibilidad para alterar sus modos de resolucindeconflictosqueparamodificarsusestilosdeinfluencia. Algunos modos de resolucin de conflictos pueden funcionar mejor que otros al aplicarlos sobre una cuestin dada, o sobre unos integrantes del grupo u otros. Sin embargo, alterar el estilo de direccin parece que les resulta ms difcil. Aunque un jefe de proyecto puede intentar tratar con sus diferentes interlocutores de forma diferente, lo ms Cristian Bailey Consultor IT Pg. 68 de 200
CMOACTAN:
probable es que en sus relaciones con una interfaz especfica utilice siempre el mismo estilo. El cambio continuo podra conducir a confusin y desconfianza por parte de sus interlocutores. 4. Cuanto menos utilizan los jefes de proyecto las bases de influencia derivadas de la organizacin como autoridad, salario y penalizacin, y ms se basan en el reto del trabajo y en el conocimiento, reciben una valoracin ms alta de su habilidad para resolver de forma eficaz los conflictos y para dirigirproyectos. El reto del trabajo est ms relacionado con la integracin de los objetivos personales de los componentes del equipo en los objetivos del proyecto que otros modos de influencia, que parecen ms proclives a adaptarlos. El reto del trabajo est principalmente orientado hacia la motivacin intrnseca del personal, mientras que los otros mtodos estn ms dirigidos hacia las recompensas extrnsecas. Y no se puede olvidar que cuando se piensa que la autoridad es inmerecida, su uso puede aumentar la conflictividad.
CMOMEJORARLAEFICACIADELJEFEDEPROYECTO:
A continuacin se muestra un conjunto de sugerencias que pueden incrementar potencialmente la eficacia del jefe de proyecto para resolver conflictos y, en ltimo lugar, para mejorar el resultado global del programa. Siempre, deben mantener y desarrollar sus conocimientos tcnicos en el campo de trabajo, ya que sin entender la tecnologa que estn manejando no se ganarn la confianza de los miembros del equipo, ni crearn credibilidad en los clientes.
La gestin eficaz de la comunicacin es uno de los principales factores que determinan la calidad del entorno organizativo. Al tener que crear el jefe de proyecto equipos a varios niveles de la empresa, es importante que las decisiones clave del proyecto, como los objetivos o las tareas de cada uno, sean comunicadas de forma apropiada a todo el personal relacionado con el proyecto. Las reuniones de revisin pueden ser un buen medio. El jefe de proyecto debe buscar un estilo de liderazgo que le permita adaptarse a las enfrentadas demandas de clientes, miembros del equipo y organizacin, sin tener miedo de variarlo si es preciso para estar en consonancia con lo que se exige en cada momento.
En cuanto a su habilidad para manejar los conflictos, deben conocer las principales causas que los determinan en su entorno y los momentos ms probables en que ocurren en la vida de los proyectos, deben considerar la efectividad de los modos de resolucin de conflictos que han utilizado en el pasado y experimentar con modos alternativos si sienten que se precisa una actuacin mejor.
Sus propias acciones influyen decisivamente en el clima de trabajo del equipo. Su preocupacin por los miembros del equipo, su habilidad de integrar los objetivos y necesidades personales de los componentes con los objetivos de ste y su capacidad para crear entusiasmo por el trabajo estimulan un ambiente de gran motivacin, involucramiento en el trabajo, comunicacin abierta y un mejor resultado final del proyecto. Los jefes de proyecto deberan tratar de acomodar los intereses y deseos profesionales de los integrantes del proyecto, cuando se les asigna sus tareas. El resultado del mismo tambin depende de lo bien que se les proporcionen trabajos desafiantes para motivarles y de lo bien que se encajen sus objetivos personales en los del proyecto.
Resumiendo, podramos decir que: LA MOTIVACIN INTRNSECA DEL PERSONAL DEL PROYECTO... MANUAL TCNICO PMI - IT Cristian Bailey Consultor IT Pg. 69 de 200
LA POSICIN DE PODER DEL JEFE DE PROYECTO... Depende de: Lugar que ocupa en la empresa El alcance y naturaleza del proyecto Autoridad que se haya ganado Capacidad de influir en la promocin y futuros trabajos de los participantes
EL EQUIPO DE TRABAJO.
Unequipodetrabajoesmuchomsquelasumadelaspersonasquelocomponen. La constitucin del equipo de trabajo es la actividad ms delicada con la que se enfrenta un Director de Proyecto, y en la que ms debe demostrar sus capacidades. El equipo es creado "ad-hoc" para una operacin determinada, y est compuesto en su mayor parte por personas sobre las que no tiene poder jerrquico, provenientes de diversos departamentos o especialidades, y que ha de funcionar como un todo armnico y ser capaz de conseguir los resultados esperados que, por definicin, son complejos, inusuales y arriesgados. Los propios empleados destacados a un proyecto pueden resistirse en ocasiones por miedo al cambio, por creer que en el proyecto van a tener que trabajar ms intensamente o por la incertidumbre sobre cul ser su puesto al reincorporarse a la unidad de origen. Ello exige un esfuerzo por parte de toda la organizacin, que requiere una mentalidad abierta y dinmica para aceptar el sentido de movilidad transitoria que caracteriza a los Proyectos. A continuacin resumimos los distintos mbitos desde los que se puede aportar personas al equipo de trabajo: Asignacin permanente: esto sucede cuando hay un grupo de personas con unos conocimientos que les permiten realizar varios proyectos dentro del mismo tema. Generalmente, esta situacin tiene reflejo en la estructura organizativa de la compaa. Asignacin temporal: son personas que se incorporan de la misma unidad organizativa para la ejecucin de ese proyecto, pero que al finalizar ste continan a disposicin del Jefe de la Unidad (no necesariamente el Director del Proyecto). Reclutamiento de nuevas personas: esta situacin se produce cuando el proyecto requiere ms mano de obra de la disponible, o con conocimientos no disponibles. Hay que tener en cuenta que, en funcin de la duracin del proyecto, esta situacin puede ser inviable puesto que el tiempo requerido para seleccionar y contratar a una nueva persona puede ser muy alto. Transferencia de personas de otros departamentos: situacin que se produce cuando hay personas disponibles en otras unidades de la organizacin. Estas personas suelen ser las que primero se le ofrecen al Director del Proyecto ante su peticin de personal, pero puede constituir una trampa al no ser las ms adecuadas. Lamentablemente, los responsables de departamento tienden a veces a considerar los empleados que trabajan bajo su mando (y que son recursos de la organizacin) como "sus" recursos, siendo remisos a desprenderse de determinada gente para aportarlos a un proyecto, cediendo a personal menos cualificado. Consultores: son siempre personas externas a la organizacin que poseen conocimientos muy especficos de los que no se dispone internamente. En muchos casos, estn ligados a las tecnologas que se van a utilizar en el proyecto. Subcontratadas: corresponden a las personas que van a ejecutar una determinada actividad que se subcontrata. No las elige el Director del Proyecto ya que pertenecen a la empresa subcontratista. Un caso particular de esta situacin es la de emplear personal ajeno a la empresa mediante una empresa de trabajo temporal que se asocia (como en el caso de la asignacin temporal) al equipo de trabajo, aunque la organizacin ejecutora del proyecto puede intervenir en el proceso de seleccin. MANUAL TCNICO PMI - IT
En muchas ocasiones la constitucin de un equipo de trabajo no se hace para un nico proyecto, sino para una lnea de actividad en la que a lo largo del tiempo se van a desarrollar diversos proyectos. Generalmente, la lnea Cristian Bailey Consultor IT Pg. 70 de 200
de actividad responde a un tipo de productos o tecnologas en los que se van a aplicar conocimientos que el equipo de trabajo posee y que no puede limitarse al proyecto que se est desarrollando. Es necesario formar a los componentes del equipo de trabajo en las tcnicas necesarias para el proyecto, puesto que aunque la seleccin del equipo de trabajo intenta obtener personas con los conocimientos necesarios, nunca es posible cumplir totalmente este objetivo, debido a: Existencia de conocimientos ligados a los procesos o productos propietarios. Entrenamiento necesario en herramientas, tecnologas o mtodos no disponibles en las instituciones educativas y caractersticas de las empresas. Obsolescencia de los conocimientos tecnolgicos o de actividad de la empresa.
As pues, es importante tener en cuenta que los conocimientos que posea un equipo de trabajo deben renovarse continuamente, aunque no sea necesario aplicarlos inmediatamente en el proyecto. Esta estrategia ayuda a cohesionar ms al equipo dndoles un marco temporal de trabajo conjunto ms amplio.
INTEGRACIN:
Dentro de un equipo humano se requiere una relacin estable para la realizacin de las tareas del proyecto. Se presentan distintos enfoques sobre la forma de proceder en este sentido: Aislamiento: la relacin entre los componentes es mnima. Las tareas se descomponen en subunidades independientes y el control se basa en relaciones jerrquicas. Interdependencia: las relaciones se maximizan, mientras que las tareas se hacen muy dependientes. Cooperacin: realizacin de tareas conjuntas. Existe un apoyo mutuo entre subunidades.
La organizacin interna de un equipo de trabajo depende fuertemente de dos factores: 1.- Tamao del equipo de trabajo: Grande. Se caracteriza por: Los costes y esfuerzo para la comunicacin dentro del equipo de trabajo son altos, requirindose la existencia de mecanismos formalizados para ello. Se requieren inversiones tecnolgicas para promocionar el trabajo en equipo. Se requiere un Director de Proyecto con ms experiencia. Pequeo. Se caracteriza por: Pueden requerirse generalistas. Puede ser adecuado un Director de Proyecto con menos experiencia. 2.- Duracin del proyecto: Corto. Se caracteriza por: Contribuciones de persona a tiempo parcial. Dificultades para justificar la recolocacin fsica del personal. Mantenimiento del Director de Proyecto en todas las fases. Largo. Se caracteriza por: Contribuciones de persona a dedicacin plena. El Director de Proyecto puede variar con las fases. Posible recolocacin fsica del equipo de trabajo. MANUAL TCNICO PMI - IT No se puede negar que el mayor valor de un grupo son las ideas, talentos y habilidades de los profesionales que lo conforman, y por lo tanto, la buena eleccin de los mismos, as como una correcta gestin en pos de aunar un conjunto de esfuerzos y conseguir unas metas comunes claramente identificadas, son la base del xito en cualquier proyecto.
SUBCONTRATACIN:
Por ltimo vamos a hacer mencin de la subcontratacin, actividad que se lleva a cabo en muchos proyectos para realizar tanto tareas rutinarias de bajo nivel de cualificacin como tareas esenciales para las que no existe personal propio cualificado, como es el caso de los consultores. Cristian Bailey Consultor IT Pg. 71 de 200
La pregunta sera: es posible controlar las competencias de las personas que van a participar en una subcontratacin? La respuesta es afirmativa. Aunque es habitual que en el proceso de seleccin de una subcontrata se analice el equipo humano que va a realizar la actividad, es necesario que ese control se realice de forma continua. Esta situacin es bsica en el caso de consultora o de proyectos de I+D en el que las decisiones se toman en funcin de la cualificacin y experiencia de las personas afectadas. En algunos sectores industriales, como el de automocin, las empresas fabricantes (ensambladores) de vehculos, prestan mucha atencin a las empresas auxiliares, manteniendo una estrecha relacin con ellas. Concretamente, apoyando sus procesos de formacin.
Pg. 72 de 200
CAPITULO 3 TIPS PARA LA GESTIN DE PROYECTOS.
REFLEXIN: "Lacalidadnuncaesunaccidente;siempreeselresultadodeunesfuerzodela inteligencia"
Pg. 73 de 200
25 SECRETOS PARA MANTENER MOTIVADO A TU EQUIPO DE TRABAJO DE PROYECTOS

De todos los recursos necesarios en un proyecto, el equipo de trabajo es el ms difcil de administrar. Si est motivado, el equipo puede hacer frente a una tarea titnica sin sudar una gota ni quejarse. Pero, cuando tenemos problemas con la motivacin, debemos de ajustar el rumbo oportunamente antes de que se nos hunda el barco. La motivacin es un todo un arte. Podemos aplicar una regla de pulgar, la motivacin es mostrar aprecio y brindar recompensa al equipo, pero cuidado! cada incentivo funciona diferente para personas distintas:
1. Siempre empezar por uno mismo: para motivar a otros se debe estar motivado y notarse en todas las situaciones.
Como lder que eres, si muestras energa y seguridad el equipo tendr confianza y te seguir convencido.
2. Siempre compartir la informacin que se tenga acerca del proyecto, el equipo debe hacer suyo al proyecto y conocer las circunstancias que le rodean y sus limitaciones, esto tambin puede llevar a que el equipo tome iniciativas para hacer sugerencias sobre nuevas formas de mejorar el proyecto. 3. Cuando nos enfrentamos a un problema relacionado con el proyecto, el equipo es nuestro mejor recurso.
Adems, podemos aprovechar la ocasin y motivar a la gente al compartir los problemas con el equipo. Propicia la participacin para buscar ideas y modos alternativos de salir del problema. Una vez que sienten que el lder tambin es parte del equipo es mas fcil llevarlos a resolver los retos del proyecto.
4. La disciplina es importante, pero hay que esforzarnos en mantener un ambiente amigable. Las personas usualmente trabajan mejor si no sienten la respiracin del jefe en su cuello. Las fechas y compromisos deben ser un reto, de tal forma que el equipo se sienta orgulloso de alcanzarlas, en lugar que sean una obligacin impuesta que ocasione discusiones si no se cumplen. 5. Los proyectos se dividen en fases, un buen administrador de proyecto motiva a su equipo al sealar los
milestones del proyecto, usualmente se puede preparar una celebracin especial al alcanzar los milestones en tiempo. Planee sus fiestas de trabajo con anticipacin o preprelas dentro del horario de trabajo. As el equipo completo podr disfrutarlas en lugar de preocuparse de otros compromisos.
6. Siempre debe mostrar aprecio por los miembros de su equipo, incluso las tareas pequeas deben terminar con al menos un gracias, las personas pueden esforzarse ms al buscar ese reconocimiento. Al comunicarse sea humilde, elija las palabras cuidadosamente, utilice ms el nosotros que el yo. 7. Durante la evaluacin el principio es no intentar culpar a nadie, pues esto puede generar un ambiente de
desconfianza. Para un buen ambiente se debe entender que es un logro de equipo o una falla de equipo.
8. Dar retroalimentacin positiva; mencione que es lo que se ha realizado correctamente, las deficiencias y como
el equipo lo puede hacer mejor. Sea parte del equipo cuando haya que responsabilizarse por una falla y termine siempre la retroalimentacin con una nota positiva.
9. Todo mundo come, vaya a comer con un miembro del equipo, platique de temas triviales incluso algunos
relacionados con el trabajo y disfruten el tiempo juntos, ser una comida gratis para ellos y un tiempo bien empleado para usted, porque al final se est trabajando en una relacin, se encuentran nuevas ideas y un colaborador sabr que es valorado. MANUAL TCNICO PMI - IT
10. Escuchar a sus colaboradores; deles espacio de tiempo en tiempo, y esmrate en escucharlos. Esto debera
ser un ritual para obtener sus perspectivas. Se pueden obtener ideas frescas que ayuden a mejorar las polticas y beneficiar al proyecto.
11. Cuando un miembro del equipo le exponga un problema sea positivo en su anlisis, trate de encontrar una
solucin definitiva para que este regrese a trabajar en ella. Incluso considera arremangarte las mangas para ayudar a llevar cabo la solucin. Esto es Ganarse el respeto con acciones y no con palabras. Pg. 74 de 200
12. Siempre apoye a su equipo, deles confianza y deles oportunidad de ganar su confianza. Es imperativo que confen en que los apoyars en caso de que estn en problemas. 13. No todo el mundo puede realizar todos los trabajos. Como lder le corresponde a usted escoger a la persona adecuada para el trabajo correcto. Aunque un miembro poco convencido de enfrentar una tarea nueva podra ganar mucha confianza al completar exitosamente el objetivo. El impacto a la moral es enorme en caso de falla. 14. Comer juntos es un constructor de relaciones, tenga comidas en equipo cuando alguien le presente algn tema relacionado con el trabajo. Bsicamente matar dos pjaros de un tiro. 15. Permitir la creatividad del equipo, la productividad del equipo aumentar si se les da un da donde puedan probar nuevas ideas, siempre y cuando tengan algo que ver con el proyecto que nos ocupa. 16. Qu es lo que hace que la gente trabaje mejor?, algunos ponen en juego las recompensas monetarias, incluso
puede ser emocionales o personales. Si logra inculcar un sentido de propiedad o pertenencia en el equipo, tomarn las metas del proyecto como metas personales, si se consigue no tendr que preocuparse por el resultado, pues la gente siempre har su mejor esfuerzo.
17. Considere la diversin, puede ser algn tiempo libre en un juego de mesa o algo similar, puede hacer equipos
de miembros junior contra veteranos y dejar que disfruten la competencia o quizs fiestas de trabajo para romper el hielo; esto ayudar a que se tomen mejor las responsabilidades, se trata de aligerar y compartir.
18. Animar es realmente valioso tanto a nivel equipo como individual para cada miembro. Cuando algo vaya bien se deben brindar elogios, un correo electrnico que reconozca una buena idea, una palmada en la espalda por una entrega temprana o elogios con el equipo o con los directivos es una excelente manera de mostrarles aprecio. 19. Cuando se solicitan ideas y retroalimentacin usualmente los miembros ms tmidos tienden a quedar rezagados. Deles a estas personas la oportunidad de adelantarse y hablar, debe escuchar cuidadosamente y
evaluar las ideas por sus mritos. Asegrese de no desalentar la participacin calificando rpidamente como una mala idea, esto podra significar que no participen ms.
20. Durante alguna discusin, si existe un punto que necesite aclararse, busque el tiempo y asegrese de pedir las aclaraciones pertinentes. Los malentendidos pueden llevar a grandes errores y estos pueden ser perjudiciales para los miembros de su equipo. Busque evitar los conflictos y resolver las situaciones antes de que puedan daar la moral del equipo o de las personas. 21. Localizar a los motivadores en su equipo, hay miembros de su equipo que muestran gran entusiasmo e incitan
a los dems miembros a hacer lo mismo sin decirlo. Identifquelos y ponga alta prioridad en su desarrollo profesional.
22. Sesiones de lluvia de ideas, estas sesiones bien llevadas pueden producir grandes ideas, adems de mostrar a sus colaboradores que son tomados en cuenta. El ser tomado en cuenta viene de la mano con la adquisicin de responsabilidades as que asigne roles de acuerdo a sus aptitudes e intereses. 23. Divida el proyecto en partes, para que pueda dar a sus colaboradores metas alcanzables. As les brindar libertad para hacer las cosas a su modo, dejndoles ganar confianza y hacer as su mejor trabajo. 24. Alcanzar metas importantes para la organizacin debe mostrar beneficios para el equipo. Pueden ser
econmicos o paquetes y prestaciones como planes mdicos, de vacaciones o algo similar.
25. Por ltimo, pero no el menos importante, considerar la pirmide de Maslow de las necesidades. No todos
tenemos la misma motivacin y necesidades. Mientras que un cierto incentivo para el trabajo puede funcionar para un miembro del equipo, no necesariamente va a motivar a los dems. Por ejemplo, si un miembro tiene algn problema financiero un aumento es lo que lo motivara mas. Pero, un miembro con ese tema resuelto pensar en Cristian Bailey Consultor IT Pg. 75 de 200
seguridad del empleo, comodidades o beneficios de otro tipo. Por lo tanto, es de suma importancia conocer bien a su equipo. Elabore una jerarqua de necesidades con esto se puede calcular la mejor motivacin y el incentivo para sus colaboradores.
FOMENTANDO LA COMUNICACIN DEL PROYECTO

La gente y sus expectativas crean un ambiente mas grande en donde los proyectos se llevan a cabo.
La comunicacin puede concretar o deshacer proyectos. Los administradores de proyectos tienen la gran responsabilidad de construir modelos de comunicacin slida que ayude, como instrumento para tener informacin clara, concisa y oportuna para atender las metas, expectativas, tareas, revisiones, retroalimentacin y el asesoramiento requerido durante el ciclo del proyecto para promover el xito y la transparencia en el proyecto. As, la comunicacin puede ser una herramienta estratgica no solo para el proyecto y comunicacin externa sino tambin para la comunicacin interna y la mejora. La administracin y comunicacin de proyectos se estn volviendo mas complejas conforme proyectos multiregiones entran al panorama. El desafo se multiplica si involucra trabajar con vendedores. Teniendo proveedores globales puede hacerlo todava ms complejo. Se debera tener un modelo robusto de comunicacin para manejar la comunicacin de proyectos internos, proyectos internos geogrficamente esparcidos proyectos de vendedores externos. El objetivo de un modelo de comunicacin debe ser: Proporcionar comunicacin precisa y concisa Involucrar a todos los stakeholders ( stakeholders = partes interesadas) necesarios y mantener contacto regularmente para mantener transparencia durante todas las transacciones. Tener canales claros de comunicacin con roles y responsabilidades bien definidas. Facilitar revisiones y retroalimentacin de las entregas de proyectos y el rendimiento del proyecto ya sea interna o externamente. Aclarar dudas, superar desafos y prevenir riesgos que afecten al proyecto Crear una relacin de confianza entre las partes. Entrenar, motivar y asesorar los equipos del proyecto. El propsito de este artculo es proporcionar informacin sobre que debera de contemplar un Administrador de Proyectos en sus modelos de comunicacin, ms all de un mero reporte del progreso del proyecto. Las siguientes secciones cubren algunos de los puntos que un Administrador de Proyectos debe tener en mente mientras idea su estrategia de comunicacin. Un buen modelo de comunicacin empieza por el principio Los Administradores deberan darse cuenta de que la comunicacin trasciende durante todo el ciclo de vida del proyecto. Un modelo de comunicacin debera ser desarrollado en una etapa temprana del proyecto, debera ser implementado en su totalidad y el plan debera mantener a los stakeholders informados en contacto en intervalos bien definidos. El plan de comunicacin debe ser construido basado en los requerimientos del proyecto y su ejecucin. Los administradores pueden tomar ventaja del histrico de informacin, normas, plantillas, etc. y adaptarlos como los requerimientos del proyecto actual lo requieran. Todos los roles necesarios y las responsabilidades deben estar claramente definidos al igual que quien tiene que comunicar que, cuando, como y donde. Se debern definir canales apropiados de escalamiento. La periodicidad de la informacin debe ser determinada, considerando los requerimientos de todos los stakeholders del proyecto. Los Administradores de proyectos deberan identificar los componentes del modelo de comunicacin, nodos de comunicacin, construir y revisar los planes de comunicacin, reconocer donde est fallando el modelo de comunicacin, reconocer la necesidad de diferentes estilos de comunicacin de los stakeholders y peridicamente evaluar la efectividad de el plan de comunicacin. La flexibilidad debe incluirse como parte del plan de comunicacin para cumplir con los requerimientos cambiantes del proyecto. Identificar a todos los stakeholders y comunicar claramente las expectativas
Pg. 76 de 200
Los Administradores de Proyectos deberan identificar todos los stakeholders y sus necesidades de comunicacin. Diversos stakeholders estarn involucrados en diferentes etapas del proyecto y sus expectativas, requerimientos y necesidades varan. Un Administrador de Proyectos debe hace hincapi en involucrar a todos los stakeholders para aprovechar la experiencia y especializacin. Mecanismos estructurados deberan usarse para conocer, priorizar y entregar requerimientos del proyecto de acuerdo a las expectativas de los stakeholders. Tambin se debera dejar claro que ser entregado en el proyecto y por que algo no ser entregado. El administrador de Proyectos debe comunicar de manera clara que se espera de los stakeholders y el tiempo y ritmo en el que sern requeridos y lo que recibirn a cambio. Cuando se trabaje con proyectos en Outsourcing, los Administradores de Proyectos del cliente y el proveedor debern determinar las lneas de comunicacin, roles y responsabilidades; quien comunicar a quien, que ser entregado. En proyectos dispersados geogrficamente, se debe tomar en cuenta el ambiente creciente, el cual trae consigo diferencias lingsticas y culturales, para asegurar que la informacin es comunicada, procesada, interpretada y absorbida como se esperaba. Si t eres un Administrador de Proyectos del proveedor, deberas saber con quien trabajar del lado del cliente. Si t eres Administrador de Proyectos del cliente, t deberas asignar una clara lnea de comando de quien se comunicar con el proveedor, quien pasar las entradas de informacin, retroalimentacin, revisiones, resultados, etc. Tambin deberas establecer una clara lnea de comunicacin de como el proveedor entreg la informacin y los entregables sern evaluados y absorbidos de regreso a la organizacin del cliente. El Outsourcing podra crear resistencia interna y un plan de comunicacin claro deber ser redactado e implementado por la alta direccin en el cual se definir como los miedos internos de la organizacin sern apaciguados, como los empleados sern motivados, como deberan de trabajar con el punto de contacto del cliente y del punto de contacto del proveedor, etc. TENGAUNROBUSTOENFOQUEALOSPROCESOS: La comunicacin del proyecto maneja la entrega y revisin de un conjunto de artefactos del proyecto. Estos incluyen los entregables del proyecto y los artefactos de comunicacin del proyecto como reportes, predicciones, retroalimentacin, etc. Procesos robustos debern estar implementados para capturar la informacin para su futuro uso. Los Administradores de Proyectos deberan determinar la entrega y documentacin necesaria para una comunicacin exitosa. Las plantillas y normas pueden ser tiles en ste mbito. MANUAL TCNICO PMI - IT
Pg. 77 de 200
Cuando se trabaje con proveedores, las plantillas que pueden ser entendidas mutuamente debern ser negociadas, incluyendo el formato, contenido, modo y frecuencia de entrega. Llevar a cabo sesiones de revisin y el capturar las lecciones aprendidas, deber ser realizado al final de cada etapa o proyecto. Ningn proyecto est terminado si no se realizan las revisiones/auditorias finales del proyecto y to todas las lecciones aprendidas deberan ser capturadas en el repositorio de proyectos de la organizacin. Todos los artefactos del proyecto y la documentacin tambin deberan ser recolectados en los activos del proceso organizacional para futuras referencias. Los registros positivos se volvern en buenas prcticas y los resultados negativos pueden servir como elementos de accin para mejorar la eficacia y eficiencia de la organizacin. Las revisiones finales deberan tambin revisar que se ha hecho bien y que podra haberse hecho bien. Cuando se trabaje con proveedores, el equipo del cliente y el del proveedor deberian revisar entre ellos en intervalos designados el progreso del proyecto y lecciones aprendidas. La comunicacin deber vigilar los remedios sugeridos durante tales sesiones y como estn siendo implementados. Procedimientos Operativos Estndar los cuales listan las suposiciones que son comnmente entendidas debern estar disponibles para evitar malos entendidos. Ambas partes deberan entender el lenguaje puesto que esto ayuda a comprender la manera de tomar decisiones. El proveedor y el cliente deberan adems proporcionar una perspectiva general de la cultura interna en vez de solo transmitir lo que se va a realizar. Al exponer la cultura interna, ayudar a que ambas partes entiendan un contexto mas grande en el que el proyecto se llevar a cabo y el entendimiento mutuo creara una relacin entre las dos partes. Un error comn es que cuando ya se han identificado las prcticas de comunicacin, rara vez son incorporadas dentro de los procedimientos de IT. Estas normas deberan de ser discutidas internamente dentro de la organizacin para hacer de los stakeholders parte integral del proyecto, programa o proceso de administracin de portafolios. Todos los stakeholders del proyecto deberan estar adecuadamente educados en estas habilidades importantes. La consistencia en la comunicacin ser mayor si el equipo se subscribe a formatos predefinidos y plantillas operacionales. Los estndares deberan estar establecidos para formato, lenguaje, nomenclatura, procesos de administracin de proyectos y componentes tcnicos. La comunicacin se vuelve mas desafiante cuando involucra equipos virtuales. Normas especficas de comunicacin y las herramientas a usar deberan ser claramente identificadas puesto que las dinmicas de grupo juegan un rol en la comunicacin asncrona entre equipos virtuales. El equipo debera tener la oportunidad de hacer borradores de protocolos que dicten cuando se debe usar cada herramienta. Cada miembro del equipo debera participar activamente en las juntas de equipo, cualquiera que sea el formato, tomando responsabilidad de ser escuchado y entendido. Mtodos ya aceptados para estar en contacto con miembros del equipo durante el ciclo de vida del proyecto son tiles y pueden servir de puntos de inicio para discutir ideas, temas e informacin. Un calendario de comunicaciones, tan detallado como el plan de administracin de comunicaciones, debera ser establecido de forma que sea flexible y pueda ser ajustado en caso de ser necesario a causa de condiciones dinmicas. Comunicacin mas frecuente podra tener que ser permitida para que los miembros del equipo se sigan sintiendo conectados. La atencin a sentimientos, prioridades y percepciones es igual de importante y se vuelve mas desafiante en un ambiente virtual cuando se transmite informacin. Los procesos de comunicacin y los procedimientos pueden requerir modificaciones para asegurar cohesin y compromiso entre los miembros del equipo. Tiempo de sobra y una agenda especfica son necesarias para una participacin completa durante las juntas. Mtodos son necesarios para revisar la comprensin. El plan debera tambin especificar quien hablar y cual ser el tiempo limite para hablar o responder a ideas o hacer sugerencias. La contingencia y medidas de seguimiento debern implementarse para manejar variables como tecnologa o la unanimidad falla en las juntas virtuales. PROMUEVASERABIERTOYLATRANSPARENCIA: El progreso de un proyecto debera ser reportado en forma oportuna con informacin precisa. El proporcionar informacin honesta, aunque esta sea negativa ayudar a tomar acciones para corregir el curso del proyecto. Los Administradores de Proyectos deberan usar las herramientas y tcnicas apropiadas para estar al tanto de los signos vitales del proyecto contra los rangos de varianza. Una vez que la varianza es identificada, los Administradores de Proyectos deberan comunicarlo a todos los stakeholders no solo para informar el estatus sino para que tambin vean si pueden ayudar con su especializacin a corregir tales varianzas. El monitoreo de la varianza y las acciones correctivas tambin deberan ser notificadas a todos los stakeholders. Este reportaje honesto no solo ayudara a tomar acciones oportunas sino tambin ayudar a cultivar confianza y responsabilidad entre los stakeholders. Los Administradores de Proyectos tambin deberan involucrar a los Cristian Bailey Consultor IT Pg. 78 de 200
miembros del equipo durante fases como finalizacin de diseo, revisin de proyecto, aceptacin de proyecto, etc. pues esto har que se sientan importantes y asuman la responsabilidad del proyecto. Involucrar a los miembros del equipo durante el levantamiento de requerimientos y diseo tambin ayudar a tener mas ideas de como cumplir, mediante un diseo de solucin ptimo, con los requerimientos propuestos. La comunicacin abierta debe ser fomentada para que todo miembro del equipo se sienta cmodo contribuyendo en las discusiones y debates. Los debates y discusiones deberan ser manejados apropiadamente para ser un foro til para proporcionar informacin, ideas y formas para compartir informacin entre el equipo. Las polticas de comunicacin deberan proporcionar un ambiente que asegure que la informacin compartida es valiosa para el proyecto. TENGAMASRESPONSABILIDADHACIALASPERSONASYMASALL: Los Administradores de Proyectos necesitan darse cuenta de que tienen un rol relacionado con los equipos de los proyectos. Los Administradores de Proyectos deberan darse cuenta que el entrenamiento y la educacin que necesitan los miembros del equipo y debera encargarse de que se obtenga. Los proyectos pueden tener efectos negativos en la organizacin y los Administradores de Proyectos deberan tener planes para minimizar lo negativo e impulsar lo positivo. Mientras haya Outsourcing, los stakeholders de la organizacin tendrn inseguridades y miedos que pueden adversamente impactar el rendimiento. Los Administradores de Proyectos deberan explicar como el desarrollo por Outsourcing puede ser beneficial al trabajo actual y cual ser el rol que cada personal interno deber jugar para contribuir en este ejercicio. Esto permitir que los empleados internos sepan no solo que estn a salvo sino tambin como trabajar bajo este nuevo escenario para absorber la sabidura y aplicarla a su trabajo actual una vez que el proveedor haga la transferencia de conocimientos y la transicin del proyecto. Los Administradores de Proyecto deberan tambin darse cuenta de que tienen la gran responsabilidad de motivar a los empleados. Un rea que los Administradores de Proyectos ignoran una vez que las fases o proyectos terminan es sentarse con los empleados para proporcionarles retroalimentacin de su rendimiento durante el proyecto. El tener revisin de compaeros o revisiones de 360 grados puede ayudar a sugerir mas contribuciones de los empleados. Los Administradores de Proyectos deberan hacer esto peridicamente, no solo para asesorar a los empleados, sino tambin para identificar las reas de mejora y ayudarlos a trazar planes para mejorar. Retroalimentacin honesta y asesoramiento puede fomentar a los individuos y crea una sana relacin con ellos. Los Administradores de Proyectos tienen mayor responsabilidad hacia la profesin de Administracin de Proyectos. Los Administradores de Proyectos pueden hablar o escribir acerca de sus experiencias de proyectos y pueden compartir sus logros y fracasos con la comunidad de la administracin de proyectos. Esto los ayuda a compartir que funcion y que no. En resumen, la comunicacin del proyecto se esta volviendo mas compleja da tras da debido al gran nmero de stakeholders involucrados y su bagaje de ideas, vistas, percepciones y puntos de vista. Un modelo slido de comunicacin apoyado por procesos debera estar implementado para explicar los requerimientos de los diversos stakeholders. Los Administradores de Proyectos deberan darse cuenta de que el motivo es incluir toda la informacin y personas necesarias y que el lema es proporcionar comunicacin honesta y oportuna acerca del proyecto. El tener un enfoque hacia la gente y el proceso es importante para hacer efectiva la comunicacin.
OFICINA DE PROYECTOS.
En la ltima dcada, ms y ms corporaciones han vivido modificaciones, a travs de una nueva estructura organizativa, capaz de centralizar todos los proyectos de la compaa, estableciendo estndares, procesos y herramientas, as como polticas comunes, con el propsito de disminuir el nmero de proyectos fallidos e incrementar los beneficios de la empresa. MANUAL TCNICO PMI - IT Ms recientemente la necesidad de obtener ventajas competitivas, producto de la globalizacin, muchas empresas han introducido en la (Project Manager Office, PMO) los recientes conceptos de negocios de pensamiento, innovacin y comportamiento organizacional, evolucionando hacia algo bueno a algo an mejor. El concepto de PMO tiene ya ms de medio siglo. La Oficina de Proyectos (PO) tuvo sus comienzos a fines de la Segunda Guerra Mundial, a travs de las instituciones militares de los EEUU. Durante las dcadas de los setenta y ochenta, las empresas de construccin incorporaron el nuevo concepto de una manera muy activa, pero casi siempre creando la oficina para proyectos grandes pero aislados. Algunas pocas empresas adoptaron la PO para estandarizar, fijar procedimientos y procesos similares en sus proyectos. Pg. 79 de 200
Posteriormente, al comienzo de los noventa, muchas empresas relacionadas con Tecnologas de Informacin (IT) y otras industrias, comenzaron a reestructurar progresivamente sus organizaciones de proyectos incorporando la PMO, al principio como una entidad tctica, o sea capaz de crear normas, procesos y seleccionar herramientas aplicables por igual a todos sus proyectos. A finales de la dcada y durante los primeros aos del siglo XXI, el concepto de seleccionar los proyectos acordes a los objetivos estratgicos de la organizacin, creando y gestionando el portafolio de planes de la empresa, empez a introducir en el entorno de proyectos, el concepto de NGPMO (Next Generation PMO) u Oficina de Administracin de Proyectos de la Siguiente Generacin. Esta idea incluye una nueva visin para realizar proyectos pensando en el concepto de negocios ms que en el de procesos, concentrndose tanto en problemas estratgicos como en situaciones de comportamiento organizacional y de recursos humanos, ms que en procedimientos y procesos tcticos. PORQUUNAPMO? Cuando las empresas empiezan a tener problemas realizando proyectos, entonces se impone la necesidad de reestructurar su organizacin. Cules son algunos de los sntomas para requerir la instalacin de una Oficina de Administracin de Proyectos?: Se arrancan demasiados proyectos y se finalizan muy pocos. Nuestros profesionales se ven desmotivados y faltos de liderazgo. Se hace sumamente difcil controlar proyectos, especialmente los ms importantes. El rendimiento promedio de nuestros proyectos es deficiente y continan en debacle a medida que transcurre el tiempo. Nuevos problemas siguen apareciendo agobiando a nuestros equipos de proyectos, quienes se encuentran continuamente en el rol de apagar fuegos. No hay suficiente tiempo para resolver todos los problemas que surgen. Demasiados problemas se convierten en crisis, algunas irrecuperables. Siempre parecemos estar faltos de recursos, tiempo y presupuesto. Cul es el proyecto que deberamos iniciar primero? Podramos terminar nuestros proyectos ms temprano reduciendo el perodo de Tiempo-al-Mercado y convirtiendo nuestros productos en verdaderas ventajas competitivas? Nuestros proyectos no estn alineados con los objetivos estratgicos de la empresa. Si algunos de estos problemas se manifiestan con demasiada frecuencia en nuestros proyectos, entonces se requiere hacer una reorganizacin que permita minimizar sus efectos y alcanzar un mayor xito.
TIPOSDEPMO: La Oficina de Administracin de Proyectos se ha dado en diferentes organizaciones con distintos sabores y colores. El concepto de PMO se ha utilizado como medio de estandarizacin creando procedimientos, procesos y herramientas para su uso comn en todos los proyectos. Tambin se ha creado para establecer un sistema de control de proyectos que permita informar a la Alta Gerencia acerca de cmo van los proyectos, convirtindose ms bien en un departamento de control de proyectos, sin establecer pautas para su realizacin. Otras PMO son de gnero autoritativo, fijando polticas y dando instrucciones para la planificacin y ejecucin de proyectos, y muchas veces usndola para vigilar y llamar la atencin al personal. Y finalmente otra versin, quizs la ms frecuente es la de tipo consultivo. En este caso, los proyectos pseudoindependientes utilizan a la PMO como a una empresa de consultora y el staff de la PMO se convierte en realidad en consultores internos, expertos en Administracin de Proyectos para apoyar a los planes que emprenda la corporacin. Muchas veces en estos casos, la PMO se convierte en un suministro adicional de recursos, enviando a los consultores como personal temporal de un proyecto determinado. Otras combinaciones de PMO estn diseadas de acuerdo al patrn que haya impuesto la propia organizacin. ALGUNOSDATOSSOBREPMO: De 450 organizaciones encuestadas por la revista PMO/CIO Magazine, dos tercios tienen PMOs. Cristian Bailey Consultor IT Pg. 80 de 200

El 50% confes que la PMO haba mejorado el resultado de sus proyectos. De esas empresas, las que tenan sus PMO instaladas desde hacia ms tiempo, informaron tener mayor xito, 37% el primer ao, 62% el segundo ao y 65% a los cinco aos. Esto sugiere que un incremento de dos tercios en el rendimiento de los proyectos puede ser un resultado a esperar. Estas empresas informaron dos razones principales para establecer una PMO: - Mejorar el ndice de xito en los proyectos. - Implementacin de prcticas estndar.
VENTAJASDEUNAPMO: Una PMO puede aportar muchas ventajas a los proyectos de la empresa y en definitiva a toda la organizacin, tales como: Uso efectivo de recursos, para aprovecharlos de manera apropiada en mayor cantidad de proyectos. Prcticas de Administracin de Proyectos estandarizadas. Uso de las mismas metodologas, procesos y herramientas, disminuyendo el tiempo de aprendizaje. Permite establecer un sistema centralizado de seguimiento y control de proyectos, capaces de producir reportes para todos los niveles de la organizacin que posibiliten una toma de decisiones rpida y efectiva. La PMO permite comunicaciones centralizadas. El conocimiento en Administracin de Proyectos est ubicado en una sola entidad y se distribuye adecuadamente a los planes que lo requieren. La apropiada recoleccin y procesamiento de lecciones aprendidas alimenta este sistema de conocimiento. Facilita una gerencia eficaz del portafolio de proyectos. Incrementa la cantidad de proyectos exitosos. Acorta el Tiempo-al-Mercado de nuevos productos desarrollados. Reduce costos en la estructura de proyectos, incrementando por tanto los beneficios de la organizacin. La PMO es un ingrediente primordial para alcanzar la madurez en Administracin de Proyectos.
LANGPMO: La PMO de la siguiente generacin, o NGPMO, enfoca sus objetivos hacia al bienestar de la empresa, ms all del rendimiento de los proyectos. El concepto ha sido explotado y est siendo madurado entre otros, por Jack Dugal del Grupo Projectize. Mientras la PMO tradicional se concentra en asuntos de tipo tctico, tales como procesos, estndares y herramientas, la NGPMO se centraliza en la estrategia de la corporacin, en su cultura y comportamiento. Los recursos humanos y su comportamiento son primordiales en las consideraciones principales de una NGPMO. Basa su accionamiento en colaboracin ms que en seguimiento y control. Provee herramientas capaces de indicar el norte a seguir. Es una estructura basada en Negocios al contrario de la PMO clsica que est basada en Procesos. La metodologa de la NGPMO es flexible y adaptable a todas las circunstancias. Los equipos de trabajo se adaptan a todas las circunstancias e innovan. La iniciativa impera en los espacios de una NGPMO. Mientras la PMO se basa en eficiencia de los proyectos, la NGPMO mide la efectividad e innovacin en la organizacin. En la PMO el liderazgo funciona por procesos y en la NGPMO funciona el liderazgo de pensamiento. Est basada en gerencia, mando y liderazgo balanceado, ms que un una gerencia de corte duro.

Lo ms importante es medir y usar mtricas que tengan sentido (al igual que con los objetivos estratgicos de la empresa). Permite comprender, liderar y nivelar el cambio en la organizacin. Capaz de repensar las Mejores Prcticas
Se basa en simplicidad. Cristian Bailey Consultor IT Pg. 81 de 200
LASCARACTERSTICASCLAVEDELANGPMOSON: Est conducida por los Negocios. Se basa en el dilogo y la colaboracin, adems, las decisiones estn fundamentadas en liderazgo. Es una PMO basada en el manejo de las relaciones y el comportamiento organizacional (PMO relations management o PRM).
As como la PMO es la ruta hacia la madurez en GP, la NGPMO muestra el camino hacia la Excelencia en Administracin de Proyectos. No todas las empresas estn en capacidad de establecer una NGPMO, pues se requerira cambiar profundamente del pensamiento y cultura de la misma. A veces la instalacin de una PMO tradicional se impone antes que una NGPMO, tratando posteriormente de migrar paulatinamente algunos de los conceptos tcticos hacia los estratgicos.
TIPS PARA LA GESTIN Y ADMINISTRACIN DE PROYECTOS.

Autoridad sin autoritarismo.
Normalmente los Lderes de Proyecto tienen algn nivel de autoridad sobre los miembros del equipo de trabajo y los recursos, dependiendo de la forma en que la empresa prefiera elaborar sus proyectos. Sin embargo, supongamos que el Lder de Proyecto cumple funciones administrativas y es el jefe inmediato de los miembros del equipo, lo cual le asigna un nivel de autoridad considerable para la administracin de los recursos que le han sido confiados. La pregunta es: cmo ejercer esa autoridad?, no hay una respuesta concreta, pues al igual que el liderazgo, depende de las circunstancias y de la personalidad del Gerente del Proyecto, sin embargo, lo que no puede suceder es que la autoridad se convierta en un autoritarismo desmedido, en donde slo primer el criterio y el querer de quien est ejerciendo esa labor. De all que deba existir un equilibrio en donde ms que autoridad (la cual debe existir) se demuestra liderazgo, de tal forma que todo el equipo sienta confianza y voluntad de seguir al Director de Proyectos.
Debe ser proactivo y no reactivo.

El Lder de Proyecto no debe ser como un bombero que anda por el proyecto apagando incendios. Su misin es la de prevenir que algn desastre ocurra, previendo las situaciones ms diversas y estructurando planes para enfrentarlas. Ante una situacin de riesgo o complicada, el buen Lder de Proyecto no pregunta Qu vamos a hacer?, sino que recurre a su plan de contingencias y sigue los procedimientos all consignados. Se requiere mucha experiencia para identificar todos los riesgos que pueden afectar un proyecto al principio de ste, es una labor que no debe ser menospreciada y estar constantemente con los sentidos bien puesta para detectar la ocurrencia de una situacin riesgosa.
Recompensar el esfuerzo.
Los miembros del equipo de trabajo no son simples recursos que ejecutan unas funciones asignadas, son personas que tienen una serie de expectativas ante la labor que desarrollan. Como lo indican varias teoras del comportamiento humano, un empleado no slo trabaja por un salario, tambin lo hace por garantizarse una seguridad social y un reconocimiento profesional. Todo esfuerzo o labor realizada, merece una recompensa para quien se ha dedicado con empeo a llevarla a cabo. El Lder de Proyecto debe inclinarse por el crecimiento personal y profesional de los miembros de su equipo y una forma de hacerlo es dando el reconocimiento adecuado a cada quien por los esfuerzos realizados.
Responsabilidad.
MANUAL TCNICO PMI - IT La responsabilidad es una cualidad inherente a cualquier persona que desempea un cargo determinado, sin embargo, para un Lder de Proyecto esta caracterstica se extiende a todos los elementos relacionados con la ejecucin de un proyecto. Es as como el Lder de Proyecto debe asumir la responsabilidad por las equivocaciones o errores que puedan cometer los miembros del equipo de trabajo, como una planeacin inadecuada, fallas en la comunicacin del estado del proyecto, malos pronsticos, y otros muchos posibles eventos. De igual forma, la calidad del producto o productos finales del proyecto estn bajo la responsabilidad del Lder de Proyecto. Es inaceptable que el mximo responsable del proyecto desve su responsabilidad sealando a otras
Pg. 82 de 200
personas de las posibles fallas que puedan presentarse, pues es su obligacin tomar los correctivos necesarios para evitar que tales situaciones sucedan.
Entregarse totalmente.
Todo proyecto debe ser para el Lder de Proyecto como la obra maestra para un artista, es decir, debe apasionarse con el proyecto, vivir el proyecto, entusiasmarse con el proyecto, dar lo mejor de s para lograr los objetivos y entregar hasta la ltima gota de sudor para ver el proyecto concluido. Todo lo anterior se logra con dedicacin y entrega. Una frase muy popular afirma que: los grandes inventos se logran con un 1% de imaginacin y un 99% de transpiracin, dando a entender que el esfuerzo y el trabajo son los factores que contribuyen en gran medida al resultado final. De alguna forma, sta sentencia puede ser aplicada a la Administracin de Proyectos, pues sin trabajo constante y comprometido por parte quienes laboran en la ejecucin de un proyecto, difcilmente podran cumplirse las metas propuestas.
Metdico.
Un Lder de Proyecto organizado tiene una metodologa para cada una de las actividades que desarrolla en funcin de su rol. Por ejemplo, tiene un mtodo para el discurrir de las reuniones de trabajo, se basa en mtodos ya definidos que le permitan crear el plan del proyecto, del mismo modo, sigue los parmetros establecidos para informar sobre el estado del proyecto, tambin sigue un marco de referencia para evaluar las propuestas de los proveedores y muchas otras actividades que requieren el seguimiento de un proceso ordenado y definido. Las metodologas y estndares adoptados son herramientas de gran utilidad en el desarrollo de las funciones de un Lder de Proyecto, pues sirven de soporte y gua, facilitando y agilizando los procesos a ejecutar.
Asumir la realidad.
Aceptar hechos y circunstancias de la forma en que se presentan, con realismo, sin perder el tiempo lamentando los errores del pasado o pensando que todo hubiese sido mejor de tal o cual modo, son caractersticas de una persona realista que sabe afrontar las situaciones en su justa medida. El Lder de Proyecto debe aceptar la realidad tal cual ella es, sin fanatismos o especulaciones y con la mente puesta en los objetivos del proyecto. En la vida cotidiana de cualquier persona, siempre se presentarn hechos y circunstancias que no son posibles remediar, sin embargo, aceptarlas en su contexto real es un buen inicio para seguir adelante. Nadie est exento de crisis familiares, personales, financieras, laborales o de cualquier tipo. El Lder de Proyecto debe ser el faro y gua para superar cualquier dificultad que se presente durante la ejecucin del proyecto.
Sentir y mostrar optimismo hacia el proyecto.
Qu pensara usted de un Lder de Proyecto que no cree en los objetivos del proyecto ni en las capacidades de los miembros de su equipo y que slo espera como resultado un fracaso?. Este Project Manager, prcticamente debera ser relevado de su posicin, pues si l como mximo responsable no tiene el grado mnimo de confianza, el proyecto fracasar evidentemente. El Lder de Proyecto siempre debe esperar lo mejor del proyecto y de los miembros de su equipo de trabajo, por lo que debe confiar en las habilidades de sus recursos y en el potencial de cualquier persona relacionada con el proyecto. El optimismo trae consigo la energa necesaria para lograr los objetivos que se pretenden alcanzar; as que es necesario contagiar a los miembros del equipo de ese espritu entusiasta, de tal forma que ellos tambin crean en s mismos y en los propsitos que han sido trazados. MANUAL TCNICO PMI - IT
Lder de Proyecto precavido vale por dos.
El buen Lder de Proyecto no permite que ciertas situaciones o acontecimientos que tienen alta probabilidad de ocurrencia lo tomen por sorpresa. Por tal razn, siempre est analizando factores de riesgo y evaluando las medidas necesarias que deben ser tomadas en el caso de ocurrencia de una situacin fortuita. Hay que reconocer que no es posible el evitar que algunas situaciones ocurran, pues no est en las manos del Lder de Proyecto esa potestad, pero lo que si debe ser posible, es el prever la forma de enfrentar esas situaciones una vez que han sido detectadas y evaluadas.
Pg. 83 de 200
Bajo ninguna circunstancia debe dejarse a la suerte a al azar el xito de un proyecto, son muchos los factores en juego para permitir que situaciones no previstas den al traste con los resultados del mismo, acabando con recursos y esfuerzos invertidos.
Tolerancia.
Un Lder de Proyecto debe saber aceptar las diferencias culturales y de opinin que puedan existir entre los miembros de su equipo o los interesados en el proyecto, pues en primera instancia debe comprender que nadie es poseedor de la verdad absoluta y el anlisis de cualquier punto de vista es vlido para enfrentar una situacin determinada. La aceptacin de la diversidad de opiniones que puedan existir respecto a un tema, sin el portar el grado o nivel de quienes las expresan, se resumen en una sola palabra: Tolerancia. Es imposible que todas las personas relacionadas con un proyecto sean ajustadas a un molde determinado y que todos piensen de la misma manera. Es necesario que aquellas diferencias de cultura, opinin o personalidad contribuyan a enriquecer los resultados el proyecto y no sean una carga pesada para el logro de los objetivos.
Respeto por los dems.
La Administracin de Proyectos no es una ciencia fra que slo est limitada a analizar, planear y controlar las actividades de los proyectos; es una actividad que incluye muchos factores metodolgicos y tcnicos, sin embargo, son las personas el componente ms valioso de un proyecto. Es por ello que el Lder de Proyecto debe interactuar con todas las personas de una forma respetuosa, dndoles la dignidad y el trato educado que se merecen como seres humanos, evitando hacer comentarios sobre defectos o comportamientos de los ausentes y exaltando siempre las virtudes de cada cual. Incluso al momento de tener una observacin hacia algn integrante de su equipo, obviamente debe hacrselo saber pero anteponiendo un comportamiento respetuoso, sin necesidad de exponer o menoscabar la dignidad del individuo. Aunque los anteriores prrafos parezcan ser tomados de un tratado de moral, hay que tomar en cuenta que tambin hacen parte del comportamiento que debe tener un buen Lder de Proyecto, cuya demostracin de tica debe estar implementada en cada actividad que realiza.
El don de saber delegar.
Un Lder de Proyecto debe reconocer que l no es la estrella del equipo y que slo es un miembro ms del grupo de trabajo, cuya misin es la de coordinar las actividades propias del proyecto. El Lder de Proyecto que lleva a cuestas toda la carga sin permitir que otras personas intervengan o contribuyan con su aporte, est cometiendo un grave error. No debe tomar todas las decisiones por s solo, confiando nicamente en su propio criterio, desechando las opiniones de otras personas con un mayor conocimiento tcnico y casi creando un culto a su persona. El Lder de Proyecto que acta con sensatez, sabe confiar en las personas que pueden tomar decisiones con un mayor nivel de conocimiento tcnico, y por tal razn, sabe delegar ciertas funciones que otros pueden desempear de una mejor manera. Lo anterior no significa que el Lder de Proyecto estar jugando un papel pasivo en tales circunstancias, por el contrario, asume la responsabilidad por los resultados derivados de una actividad delegada.
Implementacin del auto aprendizaje.
Pero cmo auto motivarse?, cmo y cundo estudiar y qu temas? No existe una nica respuesta para stas preguntas, pues depende de los vacos y expectativas de cada quien. Por lo tanto, hacer una lista de aquellos temas en los cuales se tienen lagunas, o aquellos en los cuales se desea profundizar; sera de gran utilidad, pues seran las asignaturas pendientes de aprobar. Como buenos Lderes de Proyectos, podemos crear un Plan de Carrera, Cristian Bailey Consultor IT Pg. 84 de 200
El auto estudio es la capacidad de aprender un tema especfico por cuenta propia, sin esperar a recibir la enseanza por parte de alguien ms. En nuestros das existen muchas posibilidades de obtener informacin y conocimiento haciendo uso de las modernas tecnologas disponibles. Si un Lder de Proyecto no desea quedarse en el camino muy pronto, debe adquirir cierta auto motivacin por estudiar los temas en los que es necesario mejorar o adquirir el conocimiento.
generar un proyecto cuyos objetivos sean los de aprobar tales asignaturas, en lo posible, con metas cuantificables. En cuanto a la disciplina de estudio, es recomendable proponerse una hora diaria para estudiar, o el tiempo que nuestras obligaciones nos permitan, lo ms importante es permanecer en continuo crecimiento.
Investigador.
La curiosidad forma parte de la naturaleza del hombre y ha permitido que el ser humano adquiera el conocimiento necesario para evolucionar constantemente. De igual forma el Lder de Proyecto est llamado a ser inquieto y tener la capacidad de adquirir conocimiento nuevo y valioso que le permita estar a la vanguardia de los temas ms influyentes en su labor cotidiana. Evaluar nuevas herramientas, investigar sobre nuevas tecnologas, indagar nuevos conceptos, preguntar a los colegas sobre cmo trabajan, en fin, buscar aquel conocimiento que permita replantearse continuamente su rol como Gerente de Proyectos. No es fcil adquirir la disciplina de un investigador, y mucho menos, la perseverancia necesaria para descubrir o apropiarse de un conocimiento, pero si es posible forjarse una actitud de compromiso frente a lo novedoso y desconocido.
El don del buen negociador.

Haciendo un pequeo ejercicio de smil, podramos decir que el Lder de Proyecto es como aquella persona que est en un mercado en el medio de la calle, realizando actividades de compra y venta de varios tipos de productos. Con el patrocinador acuerda recursos para el proyecto; con los stakeholders define el alcance, con los miembros del equipo valido tiempos y costos de las actividades, participa en los procesos de seleccin de proveedores, entre otros. Lo anterior obliga al Lder de Proyecto a aprender sobre tcticas y tcnicas de negociacin, a saber exponer sus argumentos con suficiente criterio, a no comprometerse con requerimientos imposibles de cumplir, a no permitir la imposicin de razonamientos no objetivos, a no permitir presiones para aceptar ofertas o propuestas sin el suficiente anlisis, en fin, aprender sobre todo aquello que signifique ser un buen negociador para impedir que por algn descuido algo salga mal en el proyecto.
Flexibilidad.
Aquella figura filosfica que ensea que un roble puede ser arrancado de tajo ante un viento fuerte por estar erguido y no someterse a la fuerza con que el ste le golpea puede ser aplicable a la forma como recibimos los acontecimientos que se presentan en nuestra vida cotidiana. El Administrador de Proyectos siempre estar expuesto a las modificaciones de las condiciones en cualquier aspecto, ya sea laboral, de mercado, familiar o personal. Ante cualquier cambio que represente un atentado a la denominada zona de comodidad, en donde se siente tan a gusto, es necesario adaptarse a con la mayor rapidez y flexibilidad posible, pues no es viable estar remando en contra de la corriente cuando se presentan circunstancias que definitivamente no se pueden controlar. En la tarea de coordinar el equipo de trabajo tambin es necesario ser flexibles ante las situaciones propias de los miembros del equipo, por ejemplo, permisos para estudiar o diligencias personales, obviamente, sin que esto altere o afecte el curso normal del proyecto.
Actualizacin y profesionalizacin permanente.
Los miembros del Project Management Institute tienen acceso a una gran cantidad de documentos y libros que permiten estar al tanto de las ltimas tendencias en las diversas vertientes que forman parte de esta disciplina. Cientos de Project Managers alrededor del mundo comparten sus experiencias y conocimientos con la comunidad de socios del PMI, lo cual resulta ser una herramienta muy valiosa para el desarrollo profesional de un Lder de Proyecto.
Pg. 85 de 200
El Lder de Proyecto debe estar siempre en la cresta de la ola de las nuevas tecnologas, las metodologas y de todo aquello que represente un avance en la disciplina de la Administracin de Proyectos. En los tiempos modernos la volatilidad es el pan nuestro de cada da y cada vez se definen ms estndares y los existentes son sometidos a una constante revisin, por lo que es imprescindible que el Director de Proyectos busque una constante actualizacin de sus conocimientos.
De igual forma, es muy recomendable la participacin en cursos, seminarios y simposios relacionados con el tema, pues es la gran oportunidad de interactuar con otros colegas y recoger de viva voz las enseanzas y experiencias que afloran en tales eventos. Adems de estar actualizado en cuanto a temas relacionados con la Administracin de Proyectos, dentro de su permanente capacitacin, el Lder de Proyecto tambin debe estar al tanto de los ltimos acontecimientos relacionados con el tipo de negocio en el que se desenvuelve o de la legislacin relacionada con la empresa u organizacin a la que presta sus servicios. El Project Manager es entonces una especie de esponja que debe tener la habilidad de absorber los conocimientos que sean necesarios para garantizar su xito como Lder de Proyecto.
Amplia visin.
Aunque no se trata de ser brujo o adivino, el Lder de Proyecto debe ser capaz de visualizar el trmino del proyecto antes de que ste inicie, lgicamente todos sus pensamientos y acciones estn dirigidos a la entrega del producto, pero sin descuidar el presente pues reconoce que el da a da ir conformando la estructura para acabar con xito determinado proyecto. De forma metafrica, el Lder de Proyecto es el dueo de un telescopio que le permite observar cualquier situacin futura con todos los detalles. Esta visin de largo plazo es una habilidad muy importante que debe desarrollar el Lder de Proyecto, pues le permitir anticiparse a los hechos, corregir desviaciones futuras y tomar decisiones con suficiente criterio. Es una bsqueda permanente del porvenir, teniendo en cuenta circunstancias y situaciones futuras que permiten remover obstculos del camino antes de tropezarse con stos. Un buen Lder de Proyecto sabe anticiparse a los hechos y tiene todo preparado para afrontar las situaciones futuras; sabe qu pasar maana, qu suceder la prxima semana, qu se espera para el prximo mes. No se trata de adivinar el futuro en una bola de cristal o de consultar el destino con un charlatn, es un anlisis serio y detallado de todo aquello que podra llegar a presentarse durante el curso del proyecto.
El rol de conciliador.
En cualquier actividad del quehacer humano es inevitable que surjan conflictos por razn de criterios encontrados, choques culturales, temperamentos, diferencias personales y por un sinnmero de circunstancias que se entretejen en las relaciones humanas. El Lder est llamado a evitar que este tipo de situaciones afecten al proyecto tratando de conciliar posiciones contrarias. Lo anterior no significa que el Lder de Proyectos sea un mediador o un rbitro para resolver diferencias personales, pues los problemas deben ser solucionados por las partes interesadas; sin embargo, siempre deben procurarse las vas y soluciones para que el proyecto no se vea afectado por ste tipo de circunstancias. Por otro lado, el Lder de Proyectos debe estar en la capacidad de armonizar las expectativas, requerimientos y deseos de los stakeholders con lo que el proyecto puede ofrecer. Por ejemplo, si un cliente propone un requerimiento que va ms all de los recursos asignados al proyecto, o si existe una solicitud por parte de un miembro del equipo de trabajo que no es posible satisfacer, stas deben ser consideradas con argumentos crebles y razonables de tal forma que el interesado o el miembro del equipo de trabajo puedan comprender la posicin del Lder del Proyecto.
No improvises.
MANUAL TCNICO PMI - IT Un Director de Proyectos experimentado sabe que la improvisacin es slo para los trovadores y no est dispuesto a tomar decisiones sin labores de anlisis y planeacin previas; sin investigar sobre el impacto y los riesgos generados por cualquier accin u omisin. Un buen Gerente de Proyectos no piensa que las cargas se arreglan por el camino como solan decir los antiguos arrieros. Cuando un Director de Proyectos decide improvisar, simplemente est creando un mayor nivel de riesgos, atentando contra los objetivos y metas del proyecto, pues acciones no medidas y sopesadas generan incertidumbre, contribuyen al caos y pueden terminar por hacer no viable el proyecto. Pg. 86 de 200
Es necesario tener mucho cuidado con la improvisacin y no permitir que miembros del equipo u otros stakeholders vayan por la vida improvisando sin ninguna clase de responsabilidad, es nuestra obligacin como Directores de Proyectos el evitar que estas situaciones se presenten y tomar todas las medidas necesarias para lograr ste objetivo.
Comuncate eficientemente con tus stakeholders y colaboradores:

Un Gerente de Proyectos pasa la mayor parte del tiempo en comunicacin con los stakeholders, con los miembros del equipo, con el sponsor, con los customers y con agentes externos al proyecto; pues una de sus funciones principales es convertir los datos relativos al proyecto en informacin til para cualquier persona interesada en el desarrollo del mismo. Por esto, una virtud del Gerente de Proyectos es la de ser un buen comunicador que sabe expresar y transmitir las ideas y resultados, con facilidad de expresin y dominio de herramientas que le sirven de ayuda en este propsito. De igual forma, el Gerente de Proyectos sabe interpretar el lenguaje verbal y no verbal, conoce el significado de gestos y modos de expresin, es claro y sin ambigedades, con buena redaccin y ortografa, incluso, con capacidad de sostener conversaciones en otros idiomas (por lo menos en ingls). El Gerente de Proyectos debe saber transmitir al equipo de trabajo los requerimientos y necesidades de la alta direccin de la empresa, y de igual forma, informa a la alta direccin sobre las inquietudes del equipo de trabajo. La relacin con los stakeholders debe ser de manera abierta, clara y concisa, con mucha cordialidad y espritu de trabajo en equipo.
Estar atento en la eleccin del equipo.
Si no intervienes en la eleccin de la gente que formar tu equipo tienes ms riesgo de pagar los platos rotos. Siempre que se puede procura involucrarte en esta decisin.
Aprende a decir que no.

Es imposible quedar bien con todos y cada uno de los stakeholders. Ofrecerles "las perlas de la virgen" y decir que s a todo slo te meter en problemas.
Recomendaciones al ejecutar un proyecto.
Para todos los desarrolladores de software dedicados a la administracin de proyectos, aqu les traemos unas breves recomendaciones que deben tener en cuenta a la hora de ejecutar un proyecto: Considerar siempre el calendario y los eventos significativos o de trascendencia. Considerar siempre el esfuerzo de trabajo, el presupuesto real, y el espacio. Considerar siempre las metas, los requerimientos y los entregables. Nunca hacer cambios en los requerimientos sin ajustar el tiempo, costo y alcance. Identificar riesgos y realizar planes de respaldo. Nunca saltar la etapa de diseo, esta ahorrar tiempo en el futuro. Realizar una buena documentacin de cdigo. Conservar el equipo, ventas y clientes enlazados. Regularmente evaluar y mejorar la productividad. Trabajar en equipo es una habilidad, aprndela, ensala y mejrala. Cuando ests estancado en algo, para ahorrar tiempo, pregunta a otros para obtener ayuda. Probar tu implementacin antes de que la liberes al equipo de pruebas. Realizar un documento de lecciones aprendidas del proyecto y mantenerlo actualizado. MANUAL TCNICO PMI - IT
Cuando el riesgo en el Proyecto es la ausencia imprevista del Project Manager:
Una de las actividades que realiza el Project Manager junto a su equipo es identificar aquellos eventos que puedan ser una amenaza u oportunidad para alcanzar los objetivos del proyecto (costos, tiempo, calidad). Las actividades para identificar, calificar, seleccionar y mitigar riesgos son constantes durante todo el proyecto. Desde el inicio hasta el final. Pero es usual que dentro de esos escenarios eventuales no se prevea la ausencia imprevista del Project Manager. Pues si el PM tambin es un riesgo. En das pasados un colega PM se ausent de manera sorpresiva y obviamente no planificada. El PM se convirti en un riesgo no identificado. Tampoco sabamos cuando se reincorporara. Urgentemente el PM seleccionado, para hacerse responsable, debe obtener informacin de manera rpida sobre: Cristian Bailey Consultor IT Pg. 87 de 200
Qu es el proyecto? Quin es el cliente? Cul es el estatus actual? Quin est en el equipo y qu est haciendo? Qu compromisos hay con el cliente? Qu se le debe entregar? Cules son las fechas importantes? La situacin anterior se logra mitigar en gran medida tomando algunas acciones prioritarias, tales como: 1. Tener un back up: En el caso de que falle el PM asignado, alguien pueda asimilar la situacin y tomar decisiones. (En una organizacin donde existe una PMO es un poco ms fcil porque se puede delegar.) 2. Estatus del Proyecto a la mano: Con un documento que indique cuales son las actividades realizadas, las prximas, los hitos por concluir y el avance del proyecto, el PM que tome el mando podr tener una idea de qu sucedi y deber suceder en las prximos das. 3. Folder fsico: En una carpeta (as como lo recomienda el artculo Herramientas esenciales para el PM) se tiene acceso a las actas de reunin, aprobaciones, documento de Alcance, etc. 4. Los archivos digitales ordenados: Saber donde estn los archivos, documentos aprobados, informacin del proyecto, etc. ayudar a identificar cualquier fuente de informacin necesaria. (Algn documento de apoyo que describa esta organizacin ser de ayuda) 5. Mails accesibles: Tener acceso a los mails del proyecto para poder verificar la informacin vital del proyecto, comunicaciones, aprobaciones, etc. 6. Cronograma pblico: Teniendo acceso al cronograma se podr saber qu se ha hecho, que se est haciendo y cules son los hitos. 7. Confianza en el equipo: Este tema es vital. El equipo sabe perfectamente qu est haciendo y que mejor que ellos para ayudar dentro de la organizacin. Una reunin con el equipo para evaluar la situacin y tomar medidas solucionar muchos inconvenientes. 8. Actitud del PM: El PM debe saber que en algn momento puede faltar y debe organizar las cosas de tal forma que puedan ser accesibles y entendibles por alguien ms.
IMPORTANCIA DEL REPORTE DE ESTADO DEL PROYECTO.

El reporte de estado debe ser un documento corto, de no ms de 2 pginas, aunque el proyecto sea grande. El propsito principal de este reporte es comunicar al receptor si el proyecto est yendo segn lo planeado y por qu. Y si no est yendo segn lo planeado, tambin por qu. Este reporte no es producido para registrar qu trabajo hizo o har el equipo del proyecto, sino que su foco es describir los desvos del plan y cmo sern corregidos. Debe constar de por lo menos los siguientes captulos: RESUMEN EJECUTIVO: un resumen que describa si el proyecto est yendo segn lo planeado, si est cumpliendo con las fechas estimadas de los hitos y fechas de entrega de los entregables. Tambin indicar: si surgieron riesgos nuevos, o aument la probabilidad o el impacto de riesgos conocidos. Tambin indicar qu acciones a corto plazo se le piden al cliente externo y/o interno, o patrocinadores, para que el proyecto sea exitoso. DETALLE DE AVANCES Y DESVOS: descripcin breve de aquellas partes del proyecto que no estn yendo segn lo planeado y qu se est haciendo para corregir este problema. Tambin datallar: hitos principales alcanzados y por alcanzar en el corto plazo. Esta seccin no es para comentar qu hizo tu equipo en el ltimo mes, sino para hablar del prximo mes: que se har para regresar el proyecto a su cauce normal. REGISTRO DE RIESGOS: indicar si surgieron riesgos nuevos o aument la probabilidad o el impacto de riesgos conocidos, por intermedio de una planilla con las siguientes columnas: Id del factor de riesgo, descripcin, plan de minimizacin, plan de contingencia, probabilidad de ocurrencia, impacto en el proyecto. MTRICAS: reportar el progreso de las mtricas elegidas para el proyecto. Por ejemplo: uso de recursos en horas, por da, das hbiles trabajados, das hbiles para finalizar, porcentaje de avance en los Cristian Bailey Consultor IT Pg. 88 de 200
entregables ms importantes, porcentaje del presupuesto total gastado, costo hasta hoy, indicadores EVM, etc. Mtricas en proyectos: Una Mtrica de un proyecto es la medida de alguna propiedad de un entregable del proyecto o del proceso de administracin de proyectos, efectuada para conocer el avance o los desvos al plan original. Si se definen mtricas acerca de un entregable especfico, estas mtricas son particulares al proyecto. Las mtricas relacionadas al proceso de administracin de proyectos pueden usarse en todo tipo de proyectos. Las mtricas pueden ser usadas para medir el estado, efectividad o progreso de las actividades de un proyecto y as contribuir a tomar decisiones estratgicas ante los desvos, incidentes o diferentes problemas que surgen en la ejecucin. Ejemplo En el contexto de un proyecto en particular, las mtricas describen las expectativas sobre un determinado entregable o sobre las tareas que se ejecutarn para producirlo.Por ejemplo, si el entregable del proyecto es "Datos convertidos al nuevo sistema y validados por el cliente interno", un grupo de mtricas podra ser: Cuntas tablas de los sistemas legacy fueron migradas al nuevo sistema hasta hoy? Cuntas tablas del nuevo sistema fueron validadas por el cliente interno hasta hoy? En qu pantallas del sistema se encuentran las tablas convertidas y cuntas de ellas han sido validadas por el cliente interno? Este conjunto de tres mtricas se medira cada semana durante el proceso de conversin, para tener una idea acerca del avance y los desvos. Para qu sirven las Mtricas? Identifican eventos y tendencias importantes en los proyectos y otorgan a la organizacin la informacin necesaria para la toma de decisiones. Sirven como vocabulario comn entre el grupo de personas que participa de la implementacin de los proyectos, y el grupo que los patrocina (Sponsors, Stakeholders). Sirven como motivacin para el equipo, porque relacionan en esfuerzo personal de los miembros con los resultados generales del proyecto.
LA DIRECCIN DEL PORTAFOLIO DE PROYECTOS TI.

La direccin de proyectos de tecnologas de la informacin se ha convertido en los ltimos aos en una pieza importante dentro del rompecabezas que un director de IT tiene que resolver para desarrollar su actividad diaria. Para responder a la actividad de las reas del negocio y a las necesidades del mercado se aaden, cambian o eliminan proyectos de forma continua a la lista de proyectos tecnolgicos a realizar. Este incremento en el nmero y variabilidad en los proyectos excede en muchos casos la capacidad del rea de IT de proveer recursos, cambiar prioridades o adaptar la infraestructura a los cambios. Como respuesta a esta problemtica, el papel que la direccin de proyectos tiene en las reas de tecnologas de la informacin ha ido creciendo ao tras ao desde mediados de los 90. En un estudio de la Universidad de Bremen y el PMI (Project Management Institute) [1] se detalla que el uso de la direccin de proyectos se extiende al 86% de las actividades de IT. Otra muestra de este crecimiento es el crecimiento en el nmero de asociados en las asociaciones de directores de proyectos que tienen en el Project Management Institute su mximo representante con cerca de 250.000 socios, proviniendo una gran parte de ellos de las reas de IT. Sin duda, este aumento en el uso de la direccin de proyectos en IT ha mejorado sustancialmente los resultados de los proyectos. En un informe del Standish Group [2] donde se estudian 30.000 proyectos de IT se muestra una evolucin desde el 1994 al 2003, donde se aprecia que los desvos en plazo han bajado del 222% en el 1994 al 63% en el 2003 y los desvos en costes desde el 189% al 49% en el mismo periodo. Viendo estos resultados podemos concluir que la direccin de proyectos ha hecho que el proyecto individual y el trabajo asociado a l se hagan mejor y que los desvos disminuyan. A pesar de ello queda todava mucho espacio para mejorar. MANUAL TCNICO PMI - IT
Pg. 89 de 200
A pesar de tener esta relevancia, la direccin de proyectos ha sido tradicionalmente estudiada y puesta en prctica desde un punto de vista muchas veces operacional, siendo la unidad de anlisis el proyecto, y sus medidas de xito restringidas a los elementos clsicos de alcance, tiempo y costes. Adems de la gestin propia del proyecto individual, los responsables de IT se encuentran con la problemtica de que para poner en marcha la estrategia de Tecnologas de la Informacin no realizan un solo proyecto con recursos dedicados, sino que tienen que gestionar un conjunto de proyectos con recursos trabajando en entornos multitarea. Para ello se encuentran con tres dificultades: la gestin de los recursos asignados a proyectos, la gestin de las interrelaciones entre los proyectos y la contribucin de los proyectos a la estrategia de IT. Para resolver estas dificultades, es necesario gestionar el conjunto de proyectos que realiza la organizacin como un todo. Con esta intencin, en los ltimos aos, se esta acuando el concepto de Direccin del Portafolio de proyectos, conocido como PPM (Project Portafolio Management). En una encuesta recientemente publicada [3] realizada a 130 responsables de IT en Estados Unidos, el 25% de los consultados aplican de forma ptima las tcnicas de la Direccin de Portafolio , 45% las aplican o las estn adoptando y el 78% las aplican, las estn adoptando o tienen planeado adoptarlas. Un portafolio de proyectos es un conjunto de proyectos que comparten y compiten por una serie de recursos y que son dirigidos dentro de una misma organizacin. Podemos considerar la direccin de portafolio como un proceso de decisin dinmico donde el conjunto de proyectos se evalan, seleccionan, priorizan y revisan de acuerdo con la contribucin a la estrategia. De acuerdo con los principios del PPM, los recursos tienen que estar asignados a los proyectos de acuerdo con la estrategia. Este movimiento de la direccin del proyecto hacia el portafolio de proyectos llev al PMI al lanzamiento de su estndar para la Direccin de Portfolio en el 2006. Este estndar representa un compendio de las mejores prcticas en la Direccin del Portafolio de proyectos [4]. Una organizacin gestiona de forma efectiva su portafolio de proyectos cuando los proyectos que forman el portafolio cumplen tres condiciones: Estn alineados estratgicamente. Maximizacin de valor. El conjunto de proyectos est balanceado. La gestin de mltiples proyectos y la direccin del portafolio de proyectos Hay que hacer una distincin entre dirigir un conjunto de proyectos y dirigir un portafolio de proyectos. En muchas organizaciones se considera que un grupo de proyectos forman un portafolio sin tener en cuenta su contribucin estratgica. En realidad un grupo independiente de proyectos no forma un portafolio, solo es un grupo de proyectos que consume tiempo y recursos. Podemos gestionarlos de la forma ms eficiente posible, optimizando la asignacin de recursos y priorizando en funcin de sta. El portafolio de proyectos tiene un claro foco estratgico, la seleccin y priorizacin ha de realizarse con una clara visin estratgica. Dentro del portafolio se busca la eficiencia, esto es que todo proyecto contribuya a la estrategia de la mejor forma posible. En la tabla 1 tenemos una comparacin de las diferencias entre la direccin de portafolio y la gestin de mltiples proyectos [5]. Direccin de Portafolio Seleccin y priorizacin de proyectos Estratgico Medio / Largo plazo Direccin de Portafolio Gestin de mltiples proyectos Asignacin de recursos Tctico Corto plazo Responsables de proyectos y recursos
Pg. 90 de 200
Propsito Foco Planificacin Responsabilidad
A menudo, la planificacin a corto plazo del grupo de proyectos responde a una incapacidad de la direccin para definir una visin y objetivos estratgicos o a una tendencia a caer en disputas polticas u organizativas (ver figura 1).
Mediante la creacin del portafolio de proyectos (ver figura 2) se establece una visin compartida entre todos los actores respecto al gobierno de los proyectos.
Las principales ventajas que conlleva la direccin de portafolio de proyectos son: Conseguimos alinear de forma dinmica los proyectos de IT con los objetivos de negocio. Maximizamos el retorno de la inversin en IT. Damos visibilidad a toda la organizacin del proceso de seleccin y priorizacin de proyectos. Conseguimos que la Direccin, las reas funcionales y el rea de IT hablen un lenguaje comn, compartan la misma visin sobre el riesgo y colaboren en el proceso de toma de decisiones. Consolidamos y reducimos el nmero de proyectos redundantes y es ms fcil evitar proyectos inadecuados. Redirigimos la inversin de IT de proyectos de bajo valor a proyectos de mayor valor. Permitimos a los responsables de recursos a planificar su asignacin de forma ms eficiente. Los proyectos deben ser priorizados basndose en su importancia relativa y en su contribucin a la estrategia. Cada proyecto debe ser priorizado relativamente a otros proyectos evaluados y a los proyectos que estn en desarrollo. Adems, a medida que el entorno tcnico y de negocio cambia, la prioridad de uno o ms proyectos tambin debe cambiar. Una vez definidas claramente las prioridades, los responsables de los proyectos y los responsables de los recursos tienen que hacerse continuamente varias preguntas crticas: (1) Se estn asignando los recursos a los proyectos de mayor prioridad? (2) Se est maximizando el uso de los recursos? (3) Finalizan los proyectos dentro de tiempo, bajo costes preestablecidos y cumpliendo los estndares de calidad? La direccin de la cartera de proyectos y la direccin de proyectos Cristian Bailey Consultor IT Pg. 91 de 200
En un informe del CIO Council sobre mejores prcticas [6] se enumeran una serie de lecciones aprendidas sobre Direccin del Portafolio de IT. La primera de estas lecciones es "Entender las diferencias y relaciones entre la Direccin del Portafolio y la Direccin de Proyectos y gestionar cada uno de la forma adecuada" Dentro de los proyectos e iniciativas que acomete un departamento de IT, la direccin del portafolio de proyectos IT se centra en el nivel agregado y se focaliza en las metas y objetivos de la organizacin. La direccin de proyectos se centra en una iniciativa especifica, definiendo y alcanzando sus objetivos dentro del coste, tiempo y rendimiento previstos. Como podemos ver en la figura 3 la direccin de proyectos genera valor a travs de la realizacin eficiente de los proyectos individuales, consiguiendo los objetivos dentro del tiempo y coste establecidos. Mientras que la direccin de proyectos genera valor a travs de la identificacin, seleccin y priorizacin de los proyectos. Podramos decir que la direccin de proyectos se centra en el proyecto, en "hacer las cosas bien" (do things right), mientras que la direccin de portafolio se centra en el conjunto y en hacer las cosas correctas (do the right thing).
La generacin de valor del departamento de IT aumenta por la direccin adecuada tanto del proyecto como del portafolio. La informacin del portafolio se obtiene a nivel del proyecto y adems de tener en cuenta el estado del conjunto, sus prioridades, nivel de riesgo, consumo de recursos y compromisos entre los proyectos. Tambin se preocupa por la salud y el buen hacer de los proyectos individuales. En la misma direccin, la mejora en la direccin de los proyectos siempre repercute de forma positiva en el portafolio. Dentro de la direccin de proyectos, los elementos que ms contribuyen a nivel de portafolio es la disponibilidad de informacin para la toma de decisiones y la eficiencia en la direccin de proyectos.
UN MODELO DE PROCESOS PARA LA DIRECCIN DEL PORTAFOLIO.

En el estndar del PMI para la direccin de portafolio [4] podemos encontrar un modelo de procesos muy detallado que nos lleva de la estrategia al portafolio y de ste a los programas y proyectos. Un modelo ms simple aparece en la figura 4 adaptada de Archer y Ghasemzadeh [7]. Este esquema de procesos nos relaciona los tres niveles, estrategia, portafolio y proyecto.
Pg. 92 de 200
El modelo empieza con la propuesta del proyecto y su anlisis individual. Este anlisis, que suele ir acompaado de un Business case, pretende hacer una evaluacin individual del riesgo y recompensa asociado a la realizacin del proyecto donde se usan criterios financieros tales como VAN, TIR y ROI y criterios de valoracin del alineamiento estratgico. Algunos proyectos son ya descartados en esta etapa. Los proyectos que pasan los criterios individuales entran en el proceso de seleccin de proyecto donde se comparan los proyectos entre ellos, tanto los proyectos que estn en ejecucin como los proyectos recin propuestos. La seleccin se basa en la evaluacin de varios criterios simultneamente mediante pesos ponderados o diagramas de burbujas. Estos criterios, al igual que en el anlisis individual de proyectos miden riesgo, beneficio y alineamiento estratgico. En la figura 5, podemos ver un diagrama de burbuja donde podramos tener una representacin de cuatro criterios, por ejemplo riesgo y beneficio en los ejes y tamao del proyecto y alineamiento en el tamao de las burbujas y el color.
Con los proyectos seleccionados se realiza un balanceo y priorizacin de los proyectos. En base a los recursos disponibles y a la valoracin previa, los proyectos se categorizan y priorizan y se asignan recursos a ellos. El seguimiento de los proyectos se realiza en base a esta priorizacin y categorizacin. El resultado de este proceso supone una actualizacin de los planes de proyectos individuales, ajustndolos a las nuevas prioridades (ver figura 6). A partir de este punto el proceso se convierte en iterativo, los proyectos se van ejecutando de acuerdo al plan actualizado y, a medida que determinadas etapas son desarrolladas, se evala continuamente el proyecto de manera individual y respecto al resto del portafolio, hasta su finalizacin o cancelacin. En el anlisis individual, la seleccin y el balanceo y priorizacin de proyectos, se hace necesario tener una estrategia de IT definida que permita una valoracin adecuada en cada uno de los pasos.
NECESIDAD DE UNA ESTRATEGIA DE IT PARA LA DIRECCIN DEL PORTAFOLIO.

Tal como hemos visto en el esquema de procesos anterior, disponer de una estrategia de IT para tu negocio es la nica forma de balancear los proyectos dentro del portafolio. Esta estrategia es necesaria para asegurar un balance entre el corto plazo: los proyectos cortos y urgentes, y los proyectos a largo plazo o importantes. Si el portafolio tiene demasiados proyectos pequeos que consumen demasiados productos, esto suele ser debido a que la estrategia no se ha definido o no se ha operacin de la forma correcta.
Pg. 93 de 200
Hemos de tener en cuenta que la estrategia se convierte en una realidad en el momento de invertir, en el caso de IT a travs de los proyectos. Por este motivo, la estrategia de IT ayuda a asignar a los recursos a diferentes proyectos, entre proyectos a corto plazo y largo plazo, entre alto riesgo y bajo riesgo, entre nuevas tecnologas y tecnologas existentes, etc.
LA PUESTA EN MARCHA DE UN PORTAFOLIO DE PROYECTOS.

Poner en marcha una direccin de portafolio de IT desde el principio no es una tarea fcil, al igual que no lo es poner en marcha la direccin de proyectos cuando la organizacin no est habituada a ello. Al abordar su puesta en marcha se ha de tener en cuenta que es un proceso de mejora continuo y es recomendable seguir un modelo de madurez, como el modelo de madurez de Kerzner [8]. Aunque inicialmente concebido para la mejora de la direccin de proyectos, es perfectamente aplicable en la implantacin del portafolio de proyectos.
LAS CINCO ETAPAS DEL MODELO DE KERZNER SON:

1. Lenguaje comn: Reconocimiento de la importancia de gestionar el portafolio de proyectos y la necesidad de una buena comprensin de los trminos, conceptos asociados a su gestin. 2. Procesos comunes: En esta etapa se definen los procesos bsicos para la direccin de portafolio de forma que el proceso sea repetible. Se aplican los principios y tcnicas de la direccin de portafolio. 3. Metodologa nica: El proceso y todos los criterios para la direccin del portafolio de proyectos (seleccin, priorizacin, evaluacin, etc.) son los mismos para todas las reas, para que as el proceso de decisin sea nico y objetivo. 4. Benchmarking: Reconocimiento de que el proceso de direccin del portafolio necesita mejorar y la evaluacin debe ser realizada de forma contina. Decidiremos que rea mejorar y qu mejorar. 5. Mejora continua: Evaluacin de la informacin de la etapa anterior y decisin de incorporarla a la metodologa existente.
Una vez puesto en marcha nuestro portafolio de proyectos ha de responder a una serie de caractersticas bsicas para su funcionamiento: Visin centralizada de los proyectos. Anlisis financiero y anlisis de riesgo. Interdependencias entre proyectos. Priorizacin, alineamiento y seleccin. Evaluacin dinmica del portafolio. Cristian Bailey Consultor IT Pg. 94 de 200
Restricciones: limitacin de recursos, capacidades del staff, de presupuesto o de infraestructura.
PRERREQUISITOS PARA LA IMPLANTACIN DE UNA DIRECCIN DE PORTAFOLIO.

Antes de empezar la implantacin de un PPM en su organizacin se han de tener en cuenta algunas precondiciones: Existencia de una estrategia de negocio y de IT: La organizacin que vaya a implantar un PPM ha de tener una estrategia de negocio y de IT definida, y comunicada a todos los departamentos involucrados. Los objetivos del PPM se ajustarn a esta estrategia. Las iniciativas de poner en marcha un portafolio sern infructuosas si no existen primero una estrategia de negocio y de IT, y nos quedaremos en una mera gestin multi-proyecto. Involucracin de la direccin: La direccin ha de estar involucrada para tener una visin integrada del portafolio y de sus proyectos. Sin el apoyo y el entendimiento total de por parte de la direccin, la competicin constante por los recurso, y los cambios de prioridad nunca sern efectivos. Habilidades del equipo: Otro aspecto relevante es la importancia de tener un equipo de proyecto con conocimientos y habilidades relevantes financieras y estratgicas.
SOFTWARE PARA LA DIRECCIN DEL PORTAFOLIO.

El aumento de inters por parte de los departamentos de IT en la Direccin del Portafolio de proyectos ha ido acompaada por una proliferacin de paquetes de software para proyectos y portafolios. La aparicin de estos paquetes de software estn ayudando al trabajo ms administrativo de recoger los datos y preparar la informacin para el anlisis. A pesar de ello el software para la direccin del portafolio est orientado a una visin ms operativa del portafolio. Son de gran ayuda para recoger datos que existen en la programacin del proyecto y agregarlos a nivel de portafolio, lo cual mejora de forma importante la gestin de los recursos. No obstante, se necesita una adaptacin para llegar a analizar el proyecto desde el punto de vista ms estratgico. En esta adaptacin tendremos que aadir informacin adicional a los proyectos que no est en su componente de programacin. La clasificacin de clientes, los clculos financieros, las etapas dentro del portafolio, las evaluaciones de riesgo, etc. Son estos ltimos, los que nos permiten una clasificacin de los proyectos segn los elementos estratgicos, maximizar el valor y balancear los proyectos y utilizar las tcnicas relacionadas con la Direccin del Portafolio.
PROCESOS CLAVE EN LA ADMINISTRACIN Y GESTIN DE PROYECTOS.

El Dr. Roger Kaufman seal en uno de sus artculos (Benchmarking) que es casi universalmente popular tomar como referencia a otras organizaciones y buscar en ellas las mejores prcticas que utilizan para que la propia organizacin pueda copiarlas y ser ms eficaz, previo a un anlisis de las mismas. Un error comn es creer que los procesos en s mismos deben ser la base para determinar la mejor prctica, sin relacionar a stos a la creacin interna de valor. Si uno busca una organizacin o metodologa como referencia, debera asegurarse de que las metas y objetivos de la institucin referente sean similares a la suya y que los procesos que se tomarn como modelo sean adecuados y funcionarn dentro de su organizacin. Si los procesos que actualmente utiliza para la gestin de proyectos o los que se propone implementar resultan en ms trabajo que el proyecto mismo, evidentemente usted necesitar repensar o simplificar dichos procesos. Eso ocurre frecuentemente con procesos propietarios o metodologas desarrolladas que no tienen en cuenta aspectos ms giles del negocio. Recuerdo un proyecto en donde me toc trabajar con otros consultores de la ex Arthur Andersen quienes utilizaban Method/1. Si bien ellos me dieron acceso a dicha metodologa francamente nunca la le, pero puedo asegurar que ocupaba toda una biblioteca, y uno debera tener mucho tiempo para poder leer todos esos libros en menos tiempo del que se necesitaba para llevarlos a la prctica. No discuto el proceso sino su usabilidad. Cualquier proceso o metodologa que ayude en el trabajo es bueno, con tal que, genere valor al cliente y no sea excesivamente pesado. Para asegurar el xito en la gestin de proyectos se necesita recurrir a las mejores prcticas del mercado y no reinventar la rueda. Los procesos o mtodos de mejores prcticas deberan ser una biblioteca de toda la experiencia pasada de una organizacin en la ejecucin de sus proyectos. Estos deberan ser modulares de manera de poder adaptarlos a los distintos tamaos o complejidades de los proyectos. La biblioteca de las mejores prcticas se Cristian Bailey Consultor IT Pg. 95 de 200
construye realizando los anlisis post-mortem o lecciones aprendidas y documentando esa informacin para la mejora continua de los mismos. Para las organizaciones que no tienen informacin histrica de proyectos anteriores o desean desarrollar la propia basndose en las mejores prcticas del mercado de metodologas existentes para la administracin de proyectos, el material de referencia estndar es el PMBOK del Project Management Institute con informacin muy detallada acerca de los procesos para la gestin de proyectos. Otras normas o metodologas tales como ISO, CMMI, Prince 2, APM, etc., son otras fuentes de informacin aunque en algunos casos son propias de determinadas industrias (IT) y otras no tan difundidas o completas. El PMBOK distribuye las mejores prcticas en 42 procesos y nueve reas de conocimiento o disciplinas. En la prctica muchos proyectos no utilizan ni la mitad de esos 42 procesos, sin embargo a los efectos educacionales el PMBOK provee la ms clara y profunda explicacin de las distintas reas que envuelven a la gestin de cualquier proyecto. La flexibilidad es muy importante aqu. Primero se trata de otro BOK (Body of Knowledge) por lo que no se espera encontrar todas las respuestas all sino que cada profesional deba consultar infinidad de otras fuentes relacionadas con cada proceso y disciplinas descriptas. Segundo, utilizar el sentido comn, la experiencia y la intuicin para decidir qu procesos son los que conviene aplicar en cada proyecto que vamos a encarar. Tomando como base el PMBOK, a mi criterio el documento que sigue siendo ms importante como referencia para la gestin de proyectos, en este artculo vamos a detallar algunos conceptos muy importantes, advertencias y temas claves que se deben contemplar en la administracin de todos los proyectos y que normalmente suelen pasarse por alto o no darles la importancia necesaria en la gestin de los mismos.
1 - SEGUIR UN PROCESO DE INICIACIN ESTRUCTURADO: realizar un estudio de factibilidad financiero, tecnolgico, de recursos, impactos, estratgico y de negocio del proyecto, para prevenir inconvenientes, priorizarlo y obtener el soporte y justificacin de negocio necesario para poder implementarlo. Durante la fase de inicio o arranque, una correcta valoracin de riesgos, asunciones, obstculos y restricciones deben ser convenientemente evaluados y el factor crtico es realizar un adecuado proceso de valoracin de requerimientos (RM) para clarificar objetivos, necesidades y alinear las expectativas. En muchos casos los procesos de RM pueden automatizarse pero siempre es conveniente mantener sesiones y reuniones con los stakeholders para aclarar los puntos grises. Todas las metodologas de administracin de proyectos recalcan la importancia de una fuerte relacin con los stakeholders y su proceso de anlisis, dado que con ellos podremos lograr ms fcilmente el xito y romper diversas barreras en los proyectos. Un error frecuente es que muchos proyectos pueden tener un gran nmero de stakeholders y el team slo dialoga con aquel ms sociable y entusiasta sin evaluar las expectativas de los otros que directa o indirectamente estn involucrados y son precisamente los que pueden ponernos los palos en la rueda. Un factor comn para el xito de los proyecto es poseer la habilidad de negociar y manejar las expectativas y necesidades de los stakeholders afectados por el proyecto. La relacin con el sponsor y los stakeholders es vital y la clave es establecer una buena relacin lo que implica ms que identificar y manejar sus expectativas, manejar una conexin emocional con la gente. El PM debe focalizarse en mejorar sus habilidades interpersonales, y asegurarse de que todos los stakeholders estn a bordo del proyecto manteniendo fluida comunicacin con ellos. El anlisis de los stakeholders debera permitir al PM no slo identificarlos sino categorizarlos bajo distintos aspectos: relacin y actitud hacia el proyecto, estn a favor o en contra del proyecto, cul es su poder e influencia, existen conflictos entre ellos, etc. 2 - PLANIFICACIN DEL PROYECTO: de acuerdo a la industria donde se realice el proyecto, la planificacin podr
tomar diferentes matices. Los proyectos para el desarrollo de software son bastante particulares, tan es as, que surgieron metodologas propias para los mismos (Agil Development) diferentes a las tradicionales como el PMBOK. Algunos aspectos de las metodologas giles pueden ser utilizados en cualquier otro proyecto. Actualmente est de moda hablar tambin de Lean Six Sigma Project Management, otra aproximacin a la gestin efectiva de proyectos. Independientemente de que se utilice una metodologa tradicional, gil o lean; una buena planificacin siempre es necesaria. En la metodologa tradicional la planificacin es exhaustiva y completa, en los ciclos ms acelerados y livianos (gil o lean) la planificacin se concentra en delimitar los bordes del proyecto para crear una lista priorizada de entregables que sern liberados en fases de tipo iterativa. Planes comprensivos, realistas y bien comunicados son imprescindibles en todos los proyectos, an con cortos ciclos de vida. Involucrar no slo al team sino a los stakeholders en el desarrollo de los planes, discutir acerca de todos los objetivos y entregables del proyecto y explicar claramente los riesgos involucrados son tambin factores esenciales. Como corolario final el consejo es no embarcarse en planificaciones extensas, construir planes a corto plazo y detallados
Pg. 96 de 200
(elaboracin progresiva segn el mismo PMBOK), e ir elaborando los requerimientos sobre la marcha en una aproximacin de tipo iterativo.
3 - UTILIZAR AUDITORAS: para evaluar la salud del proyecto, deberan realizarse auditoras y reuniones de quality assurance en forma frecuente para chequear no slo los entregables sino el estado y progreso del proyecto. Medir el progreso real versus el costo y tiempo estimado es muy importante, al igual que realizar mediciones de calidad respecto del cumplimiento de los requerimientos y el alcance de los entregables. No podemos controlar y mucho menos mejorar si no tenemos mtricas. Debemos desarrollar criterios estndar de medicin tanto de calidad como de productividad y eficiencia, para saber no slo dnde estamos sino qu y cmo debemos mejorar. El PM debe desarrollar todas las actividades y procesos definidos dentro del grupo de Monitoreo y Control del Proyecto que involucra el control del progreso del mismo (tiempo y tareas), el control del alcance (cambios), control del rendimiento (performance), control de los costos (mtodo del valor ganado) y el control de calidad. De dichos controles surgirn reportes y medidas correctivas o preventivas.
Las auditoras tambin pueden ser efectuadas por personal externo al proyecto, y se denominan peer reviews, realizadas por colegas o el departamento PMO o de Aseguramiento de Calidad. El alcance de la misma debera ser similar al comentado ms arriba. Toda auditora consta de las siguientes etapas: Planificacin: Eleccin del tipo de auditoras a realizar (costos, performance, calidad, etc.), determinar los procedimientos a utilizar, eleccin del personal, fijacin de su periodicidad (mensual, anual, espordica, etc.). Realizacin de auditoras segn procedimiento y plan definidos: Es conveniente desde el punto de vista prctico que la realizacin de auditoras sea sistemtica, y el propio director o responsable del rea a auditar transmita a sus subordinados afectados las fechas concretas en las que estas auditoras sistemticas van a realizarse para que presten su mayor colaboracin. Los documentos que recaben los resultados de las auditoras, es decir, respuestas, comprobaciones, resultados de medidas y ensayos, etc., han de estar consensuados entre auditor y auditado, de tal forma que recojan la conformidad de ambos, evitndose discusiones intiles. Se trata de auditar la efectividad de la gestin del proyecto, tanto a travs del grado de cumplimiento de los procesos, como a travs de la calidad del producto obtenido. Evaluacin de los resultados de la auditora: Toda auditora ha de realizarse para obtener una nota final que sirva, aunque slo sea comparativamente, para medir la evolucin y progreso del proyecto. Lo que se pretende es la obtencin de una valoracin totalmente objetiva por lo que el sistema de valoracin ha de ser consensuado, y adems, experimentado durante cierto tiempo, para poder fijar las seales de alerta, ndices de ponderacin, etc. Redaccin de un informe y propuesta de medidas correctivas de ser necesario, con expresindesugradodeurgencia: Una vez valorada la auditora y antes de la redaccin del informe final y propuesta de las medidas correctoras, es conveniente la reunin con el PM afectado por la auditora para que sea el primer informado y pueda incluso colaborar en la propuesta de medidas correctoras as como la decisin sobre la urgencia de las mismas, pues es conveniente que tanto el informe de la auditora como la propuesta de medidas correctoras, lo asuma como algo propio, entre otras cosas porque a veces, podr ejercer ms presin sobre la Gerencia que el propio auditor, sobre todo si alguna de las medidas propuestas corresponden o requieren inversiones.
4 - UTILIZACIN DE RECURSOS HUMANOS: la correcta utilizacin de las tcnicas blandas y el uso adecuado de las
habilidades interpersonales son factores crticos en el manejo de todos los proyectos. Un tema controversial que suele traernos dolores de cabeza se refiere a las horas que cargan los recursos al proyecto: deben ser las reales o tericas?. En las organizaciones en las que trabaj, como ocurre con muchas consultoras o empresas de servicios, al cliente se le cobra de acuerdo al proyecto un precio fijo o time & material (por hora de consultora). En ambos casos se toma para la formacin del precio el cost rate de los recursos que trabajarn en el proyecto, independientemente de que el recurso pertenezca o no a la organizacin ejecutante. Si pertenece a la organizacin y trabaja ms de 40 horas a la semana, su salario ser siempre el mismo, pero a los efectos de cobro al cliente en el caso de time & material podramos cobrar las horas overtime, algo que, en la prctica slo se le paga al recurso si es externo a la organizacin. En los casos de precio fijo, durante la planificacin normalmente calculamos en la herramienta de scheduling 40 horas de trabajo semanal. Si observamos que existen recursos con sobre alocacin (ms de 8 horas por semana) la tcnica ms comn a utilizar sera el resource-leveling algo que generalmente terminar por enviarnos el final del proyecto al lado oscuro de la luna. En la prctica normalmente no se hace nada Pg. 97 de 200
dado que el recurso si es parte de la plantilla de la organizacin, trabajar esas horas extras que por lo general y debido a su rango no son pagadas en la prctica dado que recibe su sueldo mensual fijo. El problema se presenta cuando existen sistemas de control de costos y productividad que no toma en cuenta esta realidad (dado que se maneja con planillas separadas). En estos casos es frecuente que se le obligue al recurso a cargar las horas que realmente trabaja en el proyecto en algn sistema para su registro. De ser as, estaremos en un aprieto desde el punto de vista de costos, dado que las horas cargadas y costeadas superarn lo que estaramos facturando. La nica solucin en este caso ser que no cargue sus horas extras, bajando su nivel de billability, algo que no slo puede perjudicar al recurso sino tambin al mismo gerente (problemas de utilizacin y productividad). Otro tema importante es la no disponibilidad de los recursos claves (algo frecuente en los proyectos de alta tecnologa). La demanda puede ser superior a la oferta y los planes suelen subestimar el tiempo requerido para adquirir estos recursos, lo mismo que el tiempo necesario para organizar el grupo (team building).
5 - ESTIMACIN EN LOS PROYECTOS: las estimaciones de costos y tiempos en un proyecto constituyen la parte ms
difcil en la planificacin, y es ms un arte que una ciencia. Como consultor tuve que realizar una revisin a un proyecto que estaba con un sobrecosto muy elevado y queran un anlisis de la causa de la variacin del mismo. Mi primera pregunta fue cul era el mtodo que utilizaban para las estimaciones, la respuesta clsica fue el proyecto tiene que estar listo para Octubre y se vendi en este precio considerando una determinada carga de recursos. Mi segunda pregunta fue si la base de estimacin es una ficcin, como quiere que la varianza en el costo tenga algn significado?. Lamentablemente muchas organizaciones venden sus proyectos de acuerdo a lo establecido por Ventas y no tienen tiempo de realizar una estimacin bottom-up o utilizar buenas tcnicas de mtodos cuantitativos de administracin de proyectos para al menos estimar las variaciones e incertidumbres con los buffers de contingencias necesarios. Cuanto ms largos en recursos, tiempo, costos o complejidad son los proyectos mucho ms complicada resultar la realizacin de las estimaciones. El Standish Group a travs de sus estudios empricos nos arroja estos resultados de xito/fracaso de proyectos en su relacin con su tamao y duracin.
Tamao del proyecto Debajo de $750K $750K-$1.5M $1.5M-$3M $3M-$6M $6M-$10M >$10M Personas 6 12 25 40 +250 +500 Tiempo (meses) 6 9 12 18 +24 +36 Porcentaje de xito 55% 33% 25% 15% 8% 0%
Esto nos demuestra una vez ms que los mega-proyectos pasaron de moda y que el desarrollo iterativo es el mejor mtodo para mitigar riesgos y una estrategia buena para estimar mejor el alcance, costo y tiempo de los entregables a distribuir en el proyecto.
6 - PRACTICAR UN ESTRICTO CONTROL DE CAMBIOS: independientemente del tamao del proyecto y para evitar el
Scope Creep se deber ser muy riguroso en lo que respecta al control y seguimiento de los cambios al proyecto, utilizar herramientas automticas de RM (Requirement Management) y CM (Configuration Management). Tener muy claro el procedimiento para solicitar los cambios, el tipo de formulario, cmo debe ser completado y el mtodo para aprobacin respectivo. Si el Gerente de Proyecto no ha definido bien el alcance inicial del proyecto, ser tremendamente difcil administrar el mismo. El propsito de la administracin de cambios es proteger la viabilidad de la definicin del proyecto ya definida y aprobada. Cuando se solicita formalmente un cambio implica que dicho cambio est fuera del alcance acordado en la definicin del Proyecto o de los requerimientos o solicitudes detallados durante el anlisis. Si dicho alcance es confuso, poco claro, o deja lugar a interpretaciones, entonces el cliente dir que el cambio est dentro del alcance, y el Gerente de Proyecto encontrar difcil apegarse a un proceso formal de Gestin de Alcance. En algunos proyectos es posible anticipar todas las solicitudes y requerimientos durante el proceso de anlisis. No obstante lo cual, siempre podr existir la posibilidad y la necesidad de incorporar cambios durante el ciclo de vida. Estos cambios pueden ser muy necesarios para la solucin, y pueden existir razones poderosas de negocio por las que deberan incorporarse. El Gerente de Proyecto y el equipo de trabajo, deben reconocer el momento en que los cambios son requeridos y debern seguir un proceso predefinido de gestin del alcance. Este proceso, eventualmente, proporcionar informacin para que el sponsor tome las decisiones Cristian Bailey Consultor IT Pg. 98 de 200
pertinentes y tambin le permitir decidir si la modificacin deber aprobarse en base al valor e impacto en el proyecto en trminos de costo y tiempo. Debe ser claro para todas las partes que cumplir estos nuevos requerimientos con los mismos recursos de la definicin anterior, es prcticamente imposible.
7 - BUFFERS: incertidumbre, probabilidades: son temas que hacen a la gestin cuantitativa de los proyectos. Primero y fundamental es necesario no mezclar (al menos sin identificar claramente) las contingencias que nos tomamos en las estimaciones con la duracin puesta a cada tarea. Esta contingencia debe ser claramente identificada y manejada para evitar el efecto de la famosa Ley de Parkinson. El mtodo de la Cadena Crtica coloca todas estas contingencias en un buffer compartido para todo el proyecto de uso exclusivo del PM. De no utilizar este mtodo el PMBOK nos aconseja utilizar contingencias o buffers por las incertidumbres en las estimaciones utilizando CPM/PERT, MonteCarlo, Varianza de la media, o simplemente un porcentaje del total de costo o tiempo adicional. El clculo del tamao del buffer debe tener en cuenta muchos factores. Hablar de incertidumbre en riesgos o en las estimaciones no es exactamente lo mismo que hablar de cul sera la probabilidad de ocurrencia. En forma simple, al arrojar una moneda existe una incertidumbre respecto de si saldr cara o ceca. Pero no hay incertidumbre respecto de las probabilidades de que salga cara dado que ambas tienen un 50%. Si la probabilidad de un evento se acerca ms al 100% estaremos mucho ms tranquilos porque reducimos su incertidumbre, pero inevitablemente aumentaremos su rango. Por ejemplo, si tenemos una pieza mecnica que a travs de mediciones hechas durante 5 aos sabemos que puede causar daos humanos en un impacto con rango del 35% al 45% (10%) y esto no es aceptable, lo que ocurrir es que se realizarn tareas de ingeniera para mejorar dicha pieza y reducir ese impacto negativo. Supongamos que logramos armarla de otra forma y que ahora las probabilidades de que ocurra algo malo son del rango entre 5% y 25% (20%). Hemos reducido significativamente la probabilidad de un accidente pero como no hay historia pasada el rango de la incertidumbre es ms alto (del 10 al 20%). 8 - SUBCONTRATAR DESARROLLOS EXTERNOS (OUTSOURCING): muchas veces he trabajado como prime contractor en proyectos en donde tenamos muchos proveedores involucrados (en algunos casos, su desarrollo era ms importante que el nuestro). En este aspecto son vlidas todas las recomendaciones del PMBOK sobre adquisiciones, adems de tener en cuenta todas las modalidades contractuales y de mantener el pari passu (mismas condiciones de obligaciones y responsabilidades contractuales) de las clusulas del cliente con nuestros proveedores. En este caso me referir a un tema muy corriente en el ambiente de IT que es la exigencia de ciertos niveles de calidad (CMMI) que se suele requerir cuando se contrata o se hace un outsourcing. La mayora de las empresas hoy en da pregonan ser certificadas en CMMI. Esto es imposible dado que CMMI no es una certificacin, el SEI no certifica organizaciones como el ISO o el ITSMF, sino que autoriza a personas denominadas lead appraisers a conducir auditoras para determinar el grado de madurez de la organizacin respecto del modelo. El SEI no confirma la certeza del nivel de madurez reportado, sino que su foco es ms bien la calidad continua de la organizacin, que identifique en qu nivel se encuentra y que realice todos los esfuerzos necesarios para mejorar su calidad y hacer sus procesos repetibles.
Datos de desempeo India Nmero de proyectos Programador LOC/MO Mediana de ndice por defecto/KLOC 24 209 .263 Japn 27 469 .020 31 270 .400 Estados Unidos Europa y otros 22 436 .225 Total 104 374 .150
Cundo fue publicado su ltimo assessment? (dura 2 aos) Copia de la documentacin donde figura qu reas son las ms fuertes y cules con las ms dbiles?. Cristian Bailey Consultor IT Pg. 99 de 200
El grfico mostrado ms arriba es un informe del IEEE Software que documenta un estudio sobre 104 proyectos de software en el mundo. India es el pas que proclama tener la mayora de sus empresas con Nivel 5 de CMMI y sin embargo est en el tercer lugar en cuanto a programas con errores (el informe incluye empresas como Motorola India, Infosys, Tata Consulting), algo como para tener en cuenta no?. No estoy desmereciendo la evaluacin del modelo de madurez sino que debera preguntarse mucho acerca de cmo se obtuvo y otras cuestiones de la empresa a contratar tales como:
Quin desarroll el lead assessment? Cules son sus planes de mejora continua? Con qu otros clientes trabaja? Otra caracterstica asociada a la inmadurez de nuestro mercado es el error de escuchar a un gerente decir: esta tarea ya no representa un problema porque la hemos subcontratado. Esto es falso, fundamentalmente porque la inestabilidad de nuestro mercado hace que sea muy difcil desarrollar relaciones cliente proveedores que perduren en el tiempo. Por otro lado, esta inestabilidad y lo pequeo del mercado generan el problema que los proveedores en gran medida sean Pymes, y stas permanentemente deben de tener una muy agresiva actitud de venta, sobre todo si son proveedores que dependen de la aparicin de proyectos en el mercado para tener trabajo y resulta muy difcil su evaluacin porque no hay una manera simple de saber el estado en que se encuentra dicho proveedor. Es posible analizar los contratos que tiene en ejecucin, pero no es posible analizar los contratos que estn a la firma, y muchas veces la concrecin de uno, genera mejores condiciones en las Pymes para enfrentar las negociaciones con los otros contratos, y se produce una cascada de contratos que se firman, una cantidad de compromisos simultneos que este proveedor tiene que cumplir, y como generalmente no cuenta con reservas de recursos humanos ni con una planificacin previa tiene como resultados crisis de recursos y falta de cumplimiento en todos los contratos. En el caso a su vez que el contratista sub-contrate el servicio en otra organizacin se le suma a la inestabilidad propia del contratista, que tiene sus crisis internas, las que potencian a la de los subcontratistas. Cuando bajamos de nivel, nos encontramos con empresas ms pequeas, ms inestables, ms riesgosas y ms difciles de predecir, con grandes inconvenientes para tomar buenas decisiones.
9 PROJECT MANAGER, LDER O FACILITADOR: Un Gerente de Proyecto debe desarrollar diferentes roles por lo que
es importante la ptima aplicacin de sus habilidades personales. Normalmente un PM debe cumplir con su rol de Gerente pero adems debe tambin ser el Lder del grupo de trabajo, aspectos que tienen distintos objetivos. El lector debera conocer la importancia del proceso de Team Building y cmo los grupos van madurando a lo largo del desarrollo del proyecto. Actualmente tambin podemos clasificar a los equipos de trabajo conforme a su capacidad tcnica y resolutiva, llegando a tener equipos de trabajo denominados de Alto Desempeo en donde los conflictos los resuelven entre ellos, toman decisiones propias y pueden autogestionarse. En estos casos el rol del PM ms importante es el de Facilitador donde lo que prima es dejar trabajar con libertad y preocuparse ms en eliminar los problemas u obstculos del equipo. Las caractersticas de los facilitadores son: Lideran pero no dominan; utilizan mucha escucha activa; motivan a la participacin y trabajo cooperativo; lideran con el ejemplo; mantienen al sponsor activamente involucrado pero se aseguran que no interfiera en el trabajo; documentan al nivel necesario. Estamos hablando de gente de alta confianza y estima que demuestran carisma, empata, respeto y sensibilidad por el grupo de trabajo. Podemos decir entonces que otro factor clave en la gestin de los proyectos es colocarse el sombrero adecuado teniendo en cuenta el tipo de proyecto, el team de trabajo o las circunstancias especiales que estemos controlando.
LDER Focalizado en hacer que se haga bien el trabajo Se concentra en el qu y el por qu Establece la Direccin y Metas Se asegura que los otros respondan y lo sigan Inspira, motiva, incita creacin e innovacin
MANAGER Focalizado en lograr el trabajo correcto Se concentra en el cmo Establece el Plan Ordena a los otros a completar sus tareas Ejecuta, controla, gestiona, resuelve problemas
FACILITADOR Focalizado en ayudar a la gente en el logro del trabajo Ayuda a la gente a concentrarse Ayuda a la gente a entender la Direccin y Metas Se asegura que los otros se comprometan en las tareas
10 PROJECT MANAGEMENT ESTRATGICO: el tema se basa en asegurarse de que todos los proyectos estn estratgicamente alineados y fueron previamente analizados por la PMO o un proceso de PPM. Se debe definir un criterio contra el cual todos los proyectos pueden ser priorizados que incluya el impacto en las estrategias corporativas y los clientes, y confeccionar una lista de todos los proyectos, sus metas y objetivos estratgicos. Despus, tratar de identificar el criterio de xito de los mismos y determinar el impacto esperado que cada proyecto
Cristian Bailey Consultor IT Pg. 100 de 200
Ayuda a la gente a resolver sus problemas eliminando barreras
tendr en la organizacin y sus clientes. Asignar un rango para cada proyecto cuantitativamente y determinar su nivel de prioridad. Alinear los proyectos con los planes estratgicos corporativos y departamentales, y ejemplificar cmo la ejecucin exitosa de cada proyecto apoyar la estrategia corporativa o departamental. En ciertos casos no queda otra salida que cancelar los proyectos que son de baja prioridad o que no estn ligados al plan estratgico de la corporacin o del departamento. Qu se puede hacer para implementar las mejores prcticas de Project Management Estratgico?: la retencin del conocimiento es uno de los mayores beneficios para las organizaciones ya que contribuye al aprendizaje continuo y ayuda a evitar la repeticin de errores. Con objeto de retener el conocimiento sobre la implementacin efectiva de proyectos y que puedan ser pasados como lecciones aprendidas hacia equipos de proyectos a futuro, la PMO debera tener una reunin de cierre de proyecto tan pronto como haya terminado, mientras el conocimiento sobre la administracin del mismo an est fresco en las mentes de todos. El propsito de esta reunin es revisar qu sucedi durante el transcurso del proyecto y qu puede aprender el equipo y la organizacin de lo sucedido. El sponsor del proyecto, el responsable del proyecto y el equipo de trabajo debern estar presentes as como cualquier recurso exterior o stakeholders quienes quisieran contribuir con ideas. El resultado final de esta reunin de cierre del proyecto ser la creacin de un documento formal de lecciones aprendidas para ser llevadas a proyectos futuros, a los gerentes y a sus equipos de trabajo. El establecimiento de mediciones de proyectos exitosos desde el punto de vista estratgico tambin ayudar a proveer a la alta direccin de informacin relevante y necesaria para tomar decisiones que afecten el proyecto. Por ejemplo, la presentacin estratgica de las medidas del xito del proyecto puede convencer a la alta direccin de repriorizar proyectos o de re-asignar recursos. Las medidas del xito del proyecto proveern a la PMO de la informacin necesaria para que venda el impacto de la efectividad al nivel gerencial. Los criterios para el xito en la medicin de los proyectos estratgicos deben incluir: La utilizacin de un criterio de calidad especificado. La habilidad para enfrentar cambios en los requerimientos. El nmero de recursos usados actualmente contra el nmero de recursos anticipados originalmente. La habilidad del proyecto para alcanzar sus objetivos y entregables especficos. Las encuestas de satisfaccin de clientes que indican su conformismo con el producto o la entrega del servicio del proyecto. La puesta en produccin o lanzamiento exitoso y sin problemas. Mediciones financieras adecuadas y dentro de los lmites. Finalmente, para las organizaciones que estn considerando en definir cul es la mejor metodologa para administrar sus proyectos, o cmo adaptar la metodologa del PMBOK a sus propias necesidades, la recomendacin es considerar un buen programa de entrenamiento de sus PM y considerar su posible certificacin, que ofrezca una revisin de la metodologa y las reas claves para su organizacin: costos, tiempos, riesgos, calidad, junto con una visin ms amplia, crtica y realista. Otra alternativa es contratar a una organizacin con consultores especializados y certificados PMP para que colaboren en la implementacin de los proyectos y realicen la transferencia de conocimientos y prcticas necesarias.
7 TIPS PARA ADMINISTRAR MLTIPLES PROYECTOS.

Responsabilizarse de nuevos proyectos y multi-tareas parece ser la norma en la mayora de las industrias. La buena noticia acerca de esta tendencia es que una sola persona puede obtener ms logros en menos tiempos. La mala noticia es que la mayora de nosotros no nacimos para ser multitareas. El resultado: ms trabajo de mala calidad y/o lderes desgastados y desmotivados. Los siguientes 7 tips han sido creados para ayudarte en el manejo de mltiples proyectos paralelos, sin tener que aumentar el estrs: 1.- DI NO!: Decir no podra ser imprudente. es lo primero que todos pensaramos. Es decepcionante cuando escuchamos a la gente decir que no se puede cuando le solicitamos realizar alguna tarea. Pero, es doblemente decepcionante cuando una persona dice a todo que s, y nunca termina nada de lo que se le pide. Si, con toda honestidad, consideras que no puedes completar una tarea, es mejor que digas no. Puede ser doloroso en un principio, pero te vas a ahorrar ms adelante muchos dolores de cabeza; para ti y para los dems. Puede ser que ests en una posicin donde decir que no no sea una opcin, o que tu no sea rechazado. Si es tu caso, entonces olvida este y pasa a los siguientes 6 tips. MANUAL TCNICO PMI - IT
Pg. 101 de 200
2.- PIENSA EN LA FOTO COMPLETA: Cmo es que este nuevo sombrero embona en el perchero de los sombreros? Si puedes entender cmo se acomodan todos esos proyectos para ayudar a tu organizacin a alcanzar sus objetivos, puede ayudarte a convencerte de que el esfuerzo extra vale la pena. Otra parte de la foto completa es que aprenders y crecers con la experiencia de lidiar con varios proyectos paralelos. El manejo de varios proyectos aumentar tus habilidades y capacidad para manejar ms responsabilidades en el futuro. Ver la foto completa te ayudar a identificar lo que podra ser un gran retorno sobre la inversin. 3.- DELEGA: Delega las tareas o proyectos apropiadas. Ayuda a que tu equipo aprenda a manejar ms responsabilidades. Les ests haciendo un dao si t tratas de encargarte de todo. An si el proyecto es demasiado importante para delegarlo, busca un poco de apoyo por lo menos en algunas de las tareas. Entre ms responsabilidades puedan manejar tus recursos, ms brillante ser su futuro. 4.- ORGANIZA Y PRIORIZA: No siempre lo primero que llega debe ser lo primero en despacharse. Tenemos demasiada informacin procesndose en nuestras cabezas para recordarlo todo. Los grandes lderes organizan sus responsabilidades para poder hacer ms. Y de manera similar, los grandes lderes priorizan sus responsabilidades. No es de mucho valor realizar una gran cantidad de proyectos menores cuando el proyecto de mayor prioridad se queda incompleto. Sera genial completarlos todos, pero si tienes que escoger, organiza y prioriza de manera que aproveches tu tiempo al mximo en lo que dar ms beneficios a la organizacin. 5.- NO OLVIDES! : Revisa, revisa, revisa. La mayora de los lderes estn familiarizados con la culpa de haberse desviado en la fecha de entrega. Pero, con tantas tareas que se presentan constantemente no es ninguna sorpresa que algunas de ellas se nos pasen o simplemente se retrasen. Desarrollar el hbito de revisar las fechas compromiso, tanto inmediatas como futuras, te ayudar a que estas se no se te pasen. A algunos lderes les resulta muy productivo revisar su plan de compromisos al final de cada da o al principio del siguiente. 6.- SI TE QUEDA EL SOMBRERO PNTELO: Pero, si no te queda Djalo o tralo! La justificacin de siempre lo hemos hecho as es una terrible justificacin para seguir haciendo las cosas de la misma manera. Si tienes un sombrero que ha perdido su utilidad, considera hacer algo con l. Quizs un sombrero grande debera de encogerse recortando cosas que ya no le sirvan. El sombrero puede ser manejado por alguien ms en el equipo? O quizs desecharlo sea la ltima y mejor opcin. 7.- APRENDE A HACER MALABARISMO CON LOS SOMBREROS (PROYECTOS): No te debera de sorprender que te sigan cayendo ms proyectos. La invencin del telfono no solucion el problema, ni el fax, y por supuesto que tampoco el correo electrnico. Ninguno de los inventos supuestamente ahorradores de tiempo ha funcionado como se supona. Pareciera que entre ms tiempo consigues ahorrar, ms proyectos nuevos te llegan. As que es mejor que aprendas las tcnicas para manejare varios proyectos al mismo tiempo. Normalmente aprendemos tcnicas para manejar un proyecto, pero nadie nos ensea los bemoles de administrar varios proyectos al mismo tiempo. Busca bibliografa y aprende las tcnicas especficas para administrar un portafolio de proyectos. Si eres un gerente o director de proyectos, es importante que conozcas las buenas prcticas de administracin de proyectos. Pero, no te quedes ah, ve y aprende las prcticas para administrar portafolios de proyectos.
GREEN PROJECT MANAGEMENT.

Nueva tendencia en administracin de proyectos? La administracin de proyectos verdes o Green Project Management es ms que salvar el medio ambiente (no quiere decir que eso no sea un enorme esfuerzo). Los administradores de proyectos siempre han sido verdes, tal vez sin que lo sepan. Por definicin, los project managers siempre estn constantemente intentando reducer costos, incrementar el valor para los stakeholders y proteger los recursos escasos, sin duda eso es mantener una conducta a favor del medio ambiente. En nuestra mente, todos los procesos para lograr estos nobles objetivos de la direccin de proyectos simplemente se han fragmentado y lo nico que ha faltado es colocarle la etiqueta medioambiente. Hay que recordar cuando la administracin de proyectos fue considerada una "profesin accidental. Pero gracias a las contribuciones de organizaciones como el Project Management Institute (PMI) y una gran cantidad de trabajo individual, que llevaron a esta disciplina a convertirse en una codiciada carrera, convirtiendo al lder de proyecto en el encargado de dirigir los cambios necesarios para continuar con el desarrollo, viabilidad y rentabilidad dentro de una empresa. Cristian Bailey Consultor IT Pg. 102 de 200
Con la tendencia hacia los negocios verdes, creemos que el director del proyecto es ahora "accidentalmente verde" - y no necesita serlo. Las mismas disciplinas, normas y mtodos que han hecho el director de proyectos una parte integral de los ambientes empresariales puede ser aplicada a los entornos de negocios verdes, dando lugar a un enfoque estructurado para la administracin de proyectos orientada en el bienestar ambiental. Veamos un poco ms dentro de la gestin de proyectos verdes y lo que significa un gerente de proyectos hoy en da. Si la administracin de proyectos es mucho ms que salvar al medio ambiente, entonces por qu debe tener una etiqueta verde?. Si importar si alguien es amante de los rboles o escptico al tema de preservacin del planeta, hay que aceptar la existencia de una creciente "ola verde" de ambientalismo. Las personas pueden navegar por sta, o ver desde la orilla, y no va a desaparecer. Los project managers ven sus proyectos a travs de una gran cantidad de cristales como costos,
Quienes promueven el green project management creen que un proyecto debe considerarse tambin a travs de una cristal ambiental para que el equipo del proyecto aumente su forma de pensar a largo plazo y aprovechen la mencionada ola verde. Tambin tiene sentido desde un punto de vista profesional. Slo en los EE.UU., 130 billones de dlares se han dispuesto para proyectos relacionados con energa, como parte de los gastos de estmulo del Gobierno. Qu observa un project manager a travs del cristal de medio ambiente?; Cmo ste cristal puede ayudar a definir Green Project Management?. Mirar a travs de ste permite al administrador de proyectos buscar y ver las oportunidades dentro del proyecto para ahorrar esos recursos escasos y hacerse preguntas cmo En qu parte de los procesos como diseo, planificacin, implementacin y cierre se puede ahorrar energa?. Estamos hablando de la energa humana como tal, aunque todo esto puede traducirse a la reduccin de emisiones de carbono. Por ejemplo, es ms eficiente tener reuniones virtuales que permitir que las personas viajen para tener este tipo de encuentros. Con todos los avances tcnicos en cuanto videoconferencias, stas son fciles, baratas e incluso divertidas, es casi como estar en un mismo espacio fsicamente, con la excepcin del ahorro de tiempo en traslado, gastos y consumo de combustibles de origen fsil. Debera dotarse al equipo de proyecto de herramientas virtuales que le permitan descargar y leer los documentos del proyecto y as evitar el uso innecesario de papel?. Esto tambin no sera una forma ms conveniente para los miembros a los fines de poder mantener un monitoreo permanente y revisar los documentos del proyectos, sin tener que encender sus computadoras, ahorrando as energa?. stas son nicamente un par de cosas a considerar para el equipo de proyecto, especialmente cuando se trabaja de forma remota, como parece ser la tendencia en estos das. Sin embargo existen muchas ms consideraciones para ayudar a los green project managers.
No creemos que la gestin de proyectos verdes se limita a la gestin de los aspectos ambientales de un proyecto. Creemos que est conectada a la responsabilidad social corporativa, a la triple lnea de fondo, y las cuatro Pg. 103 de 200
caractersticas de sustentabilidad establecidas por la organizacin ecologista Natural Step, la cuales son descritas como las 4 Ls: Lean, Learn, Linked and Lasting Apoyo, Aprendizaje, Vinculacin y Durabilidad. La administracin de proyectos verde se trata de personas, el planeta y beneficios. Es tambin sobre lo mencionado por el Sistema de Pensamiento de Natural Step: eliminar nuestra contribucin a la acumulacin de sustancias txicas (combustibles fsiles, metales pesados), eliminar nuestra contribucin para acrecentar txicos qumicos (DDT, PCB), eliminar nuestra contribucin para la destruccin de la naturaleza y eliminar nuestra contribucin de socavar la capacidad de las personas para satisfacer las necesidades bsicas humanas. Finalmente, Green Project Management es sobre Apoyo reducir los residuos y hacer ms eficientes las operaciones; Aprender compartir las lecciones aprendidas para crecer desde un punto de vista organizacional Vinculacin realizar la conexin con el plan de gestin ambiental de la organizacin y Durabilidad pensar a largo plazo. Hacer eso sin duda alguna que ayudar al planeta. Pero este tipo de pensamiento tambin ayudar al proyecto, as como a la organizacin. Vaya que eso suena como una gran responsabilidad colocada sobre los hombros de una sola persona que es el project manager. Pero los administradores de proyectos ya tienen las habilidades y los conocimientos inherentes para dirigir sus proyectos con intenciones a favor del medio ambiente. Es lo que hay que hacer, porque afectar positivamente a la triple lnea de fondo y ayudar al equipo de proyecto a hacer lo correcto.
Pg. 104 de 200
CAPITULO 4 DIMENSIONES DE LOS PROYECTOS.
REFLEXIN: "Lospequeosactosqueseejecutansonmeresquetodosaquellosgrandesqueseplanean"
Pg. 105 de 200
MODELO PARA LA EVALUACIN Y ADMINISTRACIN DE PROYECTOS DE TECNOLOGAS DE LA INFORMACIN.

Este modelo esta compuesto de tres dimensiones y sus respectivos componentes e interrelacin entre si.
Dimensin1: GESTIN DE PROYECTOS.

D1.1.GESTINDEPARTESINTERESADAS:
Como es conocido en un proyecto existen como mnimo dos partes, la parte interesada o contratante y la parte ejecutora. Es por ello que la gestin de partes interesadas es vital para el proyecto porque definir un Gerente de Proyecto por parte del cliente, sus funciones y atribuciones es muy importante. Ser gerente de proyecto es un trabajo de tiempo completo, ya que debe de administrar los recursos del lado del cliente, tales como: personal a colaborar en el mismo, tiempos ordinarios, tiempos extras, para realizar las tareas asignadas al cliente, as como la compra de productos o servicios complementarios que sean requeridos para la correcta ejecucin del proyecto. De igual manera de la parte ejecutora del proyecto es necesario contar con un Gerente de Proyecto que ser el responsable de administrar los recursos antes mencionados (Tal como se mencionan para el cliente sin llevar a cabo los gestiones dentro del cliente) la gran diferencia radica en la administracin del recurso tcnico que ejecuta el proyecto, debido a la variedad de recursos multidisciplinarios que se cuentan por parte de los consultores de la empresa ejecutora. Tambin se debe de delinear las mtricas de medicin del avance, para lo cual se utilizan las actividades a realizar en el proyecto por cada parte, las cuales estn incorporadas en el Gantt o Pert del proyecto respectivo. La frecuencia de las reuniones para medir los avances, la dinmica a utilizar (reunin, presentacin con Diapositivas) los indicadores de desempeo, los hitos del proyecto, los tiempos del trabajo de las partes, los feriados o das de asueto en las localidades, para que no sean motivos de atrasos o gastos innecesarios. Como ven un proyecto de implementacin de sistemas informticos es complejo en los aspectos que debe contemplar, por las mltiples dimensiones a administrar. Es valido mencionar que los proyectos de construccin son ms lineales u horizontales, a diferencia de los proyectos de informtica que son de tipo verticales y especficos a los requerimientos del mismo.
D1.2.GESTINDELALCANCE:
Quienes, como, cuando, donde y porque definen los requerimientos listados en el documento de respectivo, son importantes puntos a contemplar en la definicin de requerimientos, ya que en ocasiones se encuentran con peticiones innecesaria para la organizacin y que nicamente complacen a una persona que desea ver la informacin de una forma particular, lo cual puede elevar el nivel de dificultad del proyecto y por ende incrementar costos. Cristian Bailey Consultor IT Pg. 106 de 200
Este es el punto crtico del proyecto, debido a que en esta parte se delimitan las necesidades del cliente, lo que espera recibir y como espera recibirlo. Es por ello que el secreto para el xito de un proyecto informtico radica en la correcta definicin de estos requerimientos, la revisin a conciencia de estas necesidades, la definicin adecuada de los informes o reportes que espera recibir el cliente (recordemos que el objetivo de un proyecto de este tipo es obtener informacin oportuna, pero para esto se deben de procesar datos de la forma adecuada a los requerimientos, para que el sistema sea capaz de procesar y generar la informacin de requerida) .
Es por ello que se recomienda que las empresas tengan definidos sus procesos, en plantillas uniformes, de preferencias con plantillas de procesos de ISO 9000 para poder tener un estndar de la informacin descrita en los procesos. Es comprensible que en las empresas existan muchos procesos, y que exista resistencia a querer documentar los procesos por parte de los empleados, ya que esto en algunas culturas les genera temores indebidos. La definicin de proceso operativos del cliente es una actividad independiente al proyecto, de preferencia debe ser previa al proyecto, para as poder optimizar recursos, y tener claro el panorama de necesidades por parte del cliente. Esta definicin tambin es til para una verificacin si hay actividades duplicadas o innecesarias en la organizacin, con lo cual se lograra realizar una reorganizacin de funciones y atribuciones de la empresa. En algunos casos se habla incluso de una Reingeniera de procesos, ya que se dan cuenta que la actividades no estn correctamente desempeadas. Como comprendern la Gestin del Alcance de un proyecto de informtica es relativo a la dimensin del proyecto. Los alcances deben de cumplir con el dimensionamiento estratgico de la empresa, as como el plan estratgico de TI, Es por ello que es delicado y crucial tener correctamente definidos los requerimientos de informacin de la empresa. El proyecto se fundamenta en la correcta definicin de las necesidades de la empresa, su revisin por los gerentes responsables, y la definicin de prioridades de dichas necesidades para poder as definir las etapas y fases de trabajo del proyecto.
D1.3.ESTIMACINYCOSTEO:
Tema critico en la restructuracin correcta de un proyecto, este delimita los entregables por ende los alcances del proyecto en si. Existen generalmente 2 modalidades de presupuestos de para este tipo de proyectos, la primera y mas conocida es la de costeo por hora de servicios de consultor, la segunda de proyectos de llave en mano. Ambas modalidades son buenas, pero hay que tomar en cuenta que es una relacin gana-gana por lo cual la negociacin debe ser muy transparente en el tema de cuantificacin de los recursos necesarios para efectuar el proyecto. As como el coste de los productos y servicios necesarios para la correcta ejecucin del mismo. Al tener claro el panorama de estos temas se puede determinar que modalidad de presupuesto se propondr al cliente. Proyectos Llave en Mano: Modalidad que se caracteriza por realizar un levantado de requerimientos con el cliente, validarlos y con ello proceder a establecer los diversos renglones de trabajo con los cuales se estimaran los recursos necesarios y tomar como factor extra los imprevistos, con lo cual se puede generar el presupuestos del caso. La ventaja competitiva de este modelo de presupuesto es que si se presupuestan ms recursos y se logra ejecutar con menos recursos la diferencia es a favor del proveedor. Tomar nota importante que es ms riesgosa que todas las modalidades porque los imprevistos pueden ser mayores y no llegar a punto de equilibrio y traspasar al punto de perdida. Proyectos por Hora de servicios: Modalidad que al igual que la anterior toma como base el levantado de requerimientos con el cliente y su respectiva validacin. La diferencia radica en que las horas de servicios, las adquisicin de productos o servicios esta abierta a los requerimientos del proyecto, e inclusive si salen requerimientos extras se pueden negociar anticipadamente, e incorporar al coste del proyecto. Otra diferencia radica en la flexibilidad de cambios al proyecto segn requerimientos del cliente. Como observaran ambas metodologas de costeo y estimacin para un proyecto estn basadas en la determinacin de las necesidades o requerimientos del los clientes. Como se menciona en temas previos, el secreto y xito del proyecto radica en la definicin correcta, pero ms importante en la validacin por parte del cliente de estas necesidades as como fijar un nivel de prioridad a cada tema. Como mencionamos antes la estimacin y costeo de un proyecto de este tipo debe contemplar temas como: Recursos Humanos Cliente. (Horas Hombre) Recursos Humanos Proveedor (Horas Consultor) Hardware y Software necesarios para el proyecto. Recursos varios como Transporte, hospedaje, Alimentacin, etc. que sean necesarios para llevar a cabo el proyecto.
Pg. 107 de 200
D1.4.PLANEACINDERECURSOS:
Tema de especial atencin, ya que en este tipo de proyectos se deben de preveer todos los recursos necesarios para la implementacin del proyecto con lo cual se deben de contemplar temas como: Feriados y Das de Asueto. Proyectos alternos en los cuales se utiliza un mismo recurso. Planes de vacaciones del personal del cliente como consultores estos pueden coincidir con hitos crticos del proyecto, generando rutas crticas que colapsaran en vez de llegar a su trmino en tiempo y coste sin generar atrasos en el proyecto. Diagrama de Gantt es vital para tener un mapa del trazo del proyecto y tener claros los Hitos del mismo, pero tambin tener claro el diagrama de Pert con las respectivas rutas crticas del caso. Actividades paralelas del mismo proyecto que se pueden ejecutar anticipadamente, y sus recursos necesarios. Prestar atencin a las capacidades del recurso para ejecutar dichas actividades paralelas puesto que esto puede entorpecer la ejecucin del proyecto y en vez de ser una actividad anticipada puede convertirse en una actividad crtica por llegar a perjudicar mas adelante el proyecto. El nivel de prioridad de cada actividad determinar tambin la prioridad de los recursos a utilizar, por lo cual es importante determinarla. En los casos de compra de Hardware y Software establecer los tiempos de entrega e interaccin al pas para que estos tiempos sean contemplados en las compras del caso, Este tema es mas critico de tomar en cuenta porque depende de terceros y por ende se convierte en un factor ms complejo de manejar en la ruta del proyecto. Es conveniente que este tipo de temas sean catalogados como un Hito para que sean monitoreados con la atencin del caso. De las contrataciones de servicios de terceros o subcontrataciones para determinadas actividades o necesidades del proyecto. Estas deben ser muy analizadas porque cada proveedor tiene una cola de trabajo que debe de atender y por ende este factor puede llegar a generar atrasos en la ejecucin del proyecto. Realizar un diagnostico de Hardware y Software existente para establecer si ser necesario realizar sustituciones, las cuales deben ser presupuestadas y planificadas en el proceso del proyecto. Definicin completa de todos los recursos que necesitara el proyecto, porque con ellos se lograra anticipar la adquisicin de bienes o servicios que sern elementos para la ejecucin del mismo.
D1.5.CONTROLDEEJECUCIN:
Tema interesante porque vara entre proyectos, pero realmente se puede medir por las actividades definidas, su prioridad y tiempo de ejecucin. Los hitos son muy importantes por este tema, ya que son indicadores de la ejecucin de los proyectos. Mtricas reales de medicin de la ejecucin del proyecto se definen en el diagrama de Gantt al establecer en el mismo un porcentaje al que equivale dicho hito o actividad importante. El control de ejecucin de una proyecto de informtica generalmente es revisado y reportado por los dos gerentes de proyecto(cliente-Proveedor) ya que deben revisar las tareas o actividades asignadas a cada uno de los miembros de cada equipo segn corresponda, para que as sean validadas como positivas o negativas en la ejecucin del proyecto. Una caracterstica importante de esta actividad es que en ella se debe de mencionar lo bueno que se ha realizada en el trabajo de los equipos, pero de igual manera hacer publicas las irresponsabilidades o errores que se presenten en la ejecucin del trabajo. Mas importantes es que al reportar lo malo de un trabajo deben tener tambin las soluciones y los tiempos que conllevara solventar estas situaciones. En los casos en que se incurre en costes adicionales se debe de haces una estimacin del coste y ser aprobada por el comit del proyecto. Este tipo de seguimiento es importante de realizarse por lo menos cada quince das para tener un monitoreo del respectivo avance, tener al tanto al comit del proyecto para que se pueda conocer la trayectoria del mismo y poder tomar las decisiones pertinentes a las circunstancias. Es importante exponer por medio de una presentacin la estadstica de avances del proyecto, as como los porcentajes de avance del mismo. Es recomendable definir una plantilla que llene las expectativas de Ambas partes para que se toquen los temas de inters. La documentacin ms importante es la que deja constancia de las actividades concluidas o pendientes segn el Gantt del proyecto, este tipo de documentacin es recomendable realizarlo por medio de una minuta que sirva de Cristian Bailey Consultor IT Pg. 108 de 200
constancia del trabajo efectuado en el proyecto. Esta misma minuta debe estar amarrada a la parte contractual del proyecto, por ende a la parte de pagos o desembolsos del mismo, la misma ser instrumento de constancia de trabajo y permitir que se gestionen los pagos del caso en las reas respectivas. La minuta es una herramienta tan importante en los proyectos que es capaz de evidenciar en un mbito legal las responsabilidades de las partes en donde sea necesario. Las minutas deben ser circuladas a todos los involucrados y tomar nota que se debe proporcionar un tiempo prudente de correcciones a las mismas. L a gestin del riesgo requiere que los gerentes de proyecto y el comit sean muy visionarios para poder anticipar las consecuencias de cada accin que se ha planificado para el proyecto. Generalmente las empresas no generan planes de contingencia para casos de fallos o problemas dentro del proyecto. Como he mencionado anteriormente la correcta definicin del alcance del proyecto permite tener un plan de actividades que permitir visualizar los posibles incidentes o riegos que existen en el proceso de implementacin del proyecto. Existen diversos tipos de riesgos tales como: Valor de nuestro sistema informtico, esto es, de los recursos y la informacin a proteger. Coste de los medios necesarios para romper las medidas de seguridad establecidas en nuestro sistema. Coste de las medidas de seguridad. Personal que labora en el proyecto. Hardware utilizado en el proyecto, planes de contingencia en caso de fallos. Software utilizados en el proyecto, polticas de Back up y de restauracin de las configuraciones del sistemas a soportar. Contratos de servicios de soporte 24 x 7 para contingencias. Los antes indicados son temas o riesgos directos al proyecto, pero no debemos de olvidar temas de seguridad de la informacin que se esta manejando en el proyecto, por lo cual es recomendable tener claro el panorama de la situacin interna de seguridad de la empresa para proteger aspectos como: Vulnerabilidad fsica Vulnerabilidad natural Vulnerabilidad del hardware y del software Vulnerabilidad de los medios o dispositivos Vulnerabilidad por emanacin Vulnerabilidad de las comunicaciones Vulnerabilidad humana Tipos de amenazas: Intercepcin Modificacin Interrupcin Generacin Amenazas naturales o fsicas Amenazas involuntarias Amenazas intencionadas Para ampliar estos temas pueden consultar el documenta denominado aspectos para auditoras de sistemas de informacin y tecnologas informticas e implementacin de estndares de seguridad informtica.
D1.6.GESTINDERIESGOS:
D1.7.GESTINDELASCOMUNICACIONES:
En el mundo de hoy las empresas cuentan con mltiples oficinas en diversas localidades o pases y por ende hay que interactuar con estas otras instalaciones ya que el proyecto es para bien comn. Por este entorno de mltiples localidades se debe establecer comunicacin con el personal que interacta en las diversas fases del proyecto. Este entorno mas complejo involucra temas muy relacionados con la comunicacin y
Pg. 109 de 200
es los canales para efectuar las mismas, por ello es que las telecomunicaciones son elementales en el proceso de la gestin de los proyectos. Generalmente en la regin latinoamericana las telecomunicaciones estn muy avanzadas en las zonas urbanas, pero no todas las oficinas de las empresas estn reas urbanas, por lo cual es posible que no tengan acceso a todos los servicios de comunicacin que se tienen el las zonas citadinas. Por ejemplo el proyecto puede tratarse de la implementacin de un ERP, lo cual significa que el sistemas estar centralizado y que las oficinas externas a la central de la empresa debern de acceder de forma remota, para lo cual es necesario tener enlaces de telecomunicaciones, pueden ser de tipo punto a punto o Internet, para que por medio de una VPN se canalice el trafico del sistema a implementar. Este tipo de infraestructura fsica y lgica debe estar prevista en el plan de trabajo del proyecto, debido a que se deben de evaluar las necesidades y proceder a realizar los planes de contratacin de servicios antes mencionados y utilizar el Software de acceso remoto para poder as optimizar los anchos de banda, recordemos que estos enlaces generalmente se utilizan para mas de un servicio, tales como: Voz sobre IP. Correo electrnico. Salida de Internet. VPN. Traslado de Archivos en la Intranet. Etc. Es por ello que la parte de comunicaciones es ms compleja que simplemente planificar las reuniones y comunicar o capacitar a las partes involucradas en el proyecto. Anteriormente se menciono que es muy til tener una evaluacin de la situacin actual de la empresa a que se le implementara el proyecto para poder hacer las previsiones del caso y por ende hacer los requerimientos de recursos con la anticipacin necesaria para que no se conviertan problemas. De ser necesarios instalar enlaces se deber de catalogar como una ruta critica por la dependencia de terceros y posibles incumplimientos.
D1.8.GESTINDEADQUISICIONESYCONTRATOS:
Un tema muy interesante de manejar en el proyecto, debido a que los temas de adquisiciones y/o contrataciones como se sabe son dependientes de terceros, para lo cual se deben de evaluar la trayectoria del proveedor, la calidad de productos o servicios que prestara y sus recomendaciones. La contratacin de este tipo de servicios o productos debe ser planificada anticipadamente para que se cuente con tiempo de holgura por posibles atrasos imprevistos en el proyecto. En el presente documento se ha mencionado temas de este tipo, debido que es factible que se encuentre con un proveedor que incumpla y por ende dae el trayecto del mismo. La parte contractual o legal que una contratacin debe contemplar es muy importante porque es donde la empresa se puede defender de posibles incumplimientos, se debe contemplar sanciones o fianzas de cumplimiento para que se realice el cubran estos inconvenientes. Es comn que la gente de sistemas no tenga conocimientos de este tema, por lo cual se deben de apoyar en un departamento legal que genere un contrato capaz de proteger los intereses del proyecto. Recordemos que las negociaciones son Gana-Gana por lo cual un contrato que tiene amonestaciones tambin debe tener premios por diversas situaciones. Es all donde se debe negociar un contrato que satisfaga a ambas partes. Estos aspectos se deben de considerar en esta gestin de Adquisiciones y contratos: La necesidad de contratar El contrato Rangos en la contratacin Cristian Bailey Consultor IT Pg. 110 de 200

Con quien contratar Ambiente de negociacin Anlisis de las propuestas Requisitos mnimos de un contrato Garantas Clusulas indispensables Perfeccionamiento del contrato Responsabilidades Convenios de confidencialidad
Como observaran son muchos los aspectos a contemplar en este tipo de procesos por lo cual es muy importante contar con la accesoria del caso para que el proceso no se vea perjudicado en algn momento.
D1.9.GESTINDETALENTOHUMANO:
Cuando hablamos de Gestin de Recursos Humanos nos estamos refiriendo a la gestin de las personas que conforman la organizacin; y estamos, en este caso, hablando de la gestin del principal recurso del que disponen las organizaciones para mantener y mejorar su competitividad. Por qu esta importancia, cada vez mayor, al recurso humano? Nos encontramos en un ambiente en el que las tecnologas, los mercados, los productos... cambian muy rpidamente; en un ambiente en el que la innovacin y la actividad centrada en el cliente son dos de las principales armas estratgicas de que disponen las empresas. Y son las personas que conforman la organizacin las que van a innovar y las que van a conseguir que los clientes estn o no satisfechos. En el rea de la gestin de proyectos, la gestin de recursos humanos es un elemento fundamental. La creacin del equipo de trabajo es bsico para que el proyecto se pueda realizar bien. La figura ms importante la representa el Director de Proyecto, ya que su estilo de direccin y la forma de resolver los conflictos influye de manera decisiva en la marcha del proyecto. En esta seccin presentamos las siguientes divisiones: El equipo de trabajo. Cmo se constituye, quienes lo integran, caractersticas... Perfiles tpicos de los integrantes. Director tcnico del proyecto, organizacin del equipo. Conflictos. Causas, cmo resolverlos.
El error humano es comn, por mltiples temas, por lo cual debemos de tener en cuenta que el capital humano puede generar situaciones que afecten el correcto desempeo del proyecto. Es por ello que monitorear frecuentemente el desempeo de las personas involucradas, su situacin personal o emocional, aprendizaje en las capacitaciones, nivel de Pro actividad en el proyecto, para poder determinar si se genera un plan de incentivos a los mejores miembros de los equipos de trabajo. Los proyectos que manejan y presupuestan incentivos a los mejores empleados que colaboran con el mismo, son beneficiados en gran medida. Es conveniente hacer eventos para publicar el buen desempeo del personal y los grandes avances del proyecto.
D1.10.GESTINDEDOCUMENTACIN:
Al mismo tiempo se pueden tomar decisiones de modificar partes del proyecto en si, debido a las circunstancias del entorno empresarial, por lo cual es vital tener documentado los cambios, acuerdos y razones por las cuales se toman estas determinaciones. En los proyectos de informacin y tecnologa se generan configuraciones de Hardware y Software que deben ser documentadas para posteriores reconfiguraciones. Cristian Bailey Consultor IT Pg. 111 de 200
Este tema se relaciona a la bitcora de actividades del proyecto, tomen en cuenta que en un proyecto de este tipo generalmente se realizan una serie de actividades, entrevistas y reportes que generan datos para ser procesados y as generar un proceso o requerimiento especfico para el proyecto.
Adems los controles de cambios a las configuraciones iniciales es muy importante de documentar. Se recomienda que para esta parte se usen metodologas de documentacin como las de ITIL o RUP que poseen bases slidas para generarla. De especial importancia es la documentacin en proyectos de Gestin empresarial en la cual se implementan sistemas como son:

ERP. CRM. SCM. RRHH. Etc.
Como ustedes saben este tipo de sistemas son parametrizados segn los procesos y necesidades de la organizacin, por lo cual es muy importante dejar documentadas las configuraciones que se le da al sistema, muy especialmente si se generan desarrollos complementarios al sistema ya existente. Las bitcoras de desarrollo son esenciales para la conclusin correcta del proyecto. Otra parte importante de documentar es la relacionada a los reportes que generan informacin, ya que generalmente tienen cierto nivel de complejidad por lo cual es recomendable tener bien definidos los puntos donde son estructurados los extrados los datos que conforman la informacin del reporte respectivo. Temas de seguridad, infraestructura, telecomunicaciones y sistemas de soportes perifricos tambin se deben de documentar, bajo las normativas de COBIT para tener un estndar de dicha documentacin.
Pg. 112 de 200
Pg. 113 de 200
Dimensin2:ASPECTOSTCNICOS.
D2.1.DEFINICINDEREQUERIMIENTOS.
Como mencionamos antes este tema es fundamental en la estructuracin del proyecto, es por ello que se le dedica tanta atencin, ya que en ellos radica la magnitud del compromiso, las horas de trabajo, los recursos necesarios, por ende el costo total del proyecto, Para este efecto es conveniente realizar una matriz de requerimientos versus compromisos de entrega, adems de colocar el nivel de prioridad por medio de una valoracin que permita determinar la importancia. Suena complejo, pero es mas sencillo de lo que se imaginan si existe un entendimiento claro de lo que el cliente requiere y el consultor de rea funcional puede hacer un punto de validacin de la ejecucin del requerimiento e indicar que si se puede cumplir. Aspectos a considerar en los requerimientos: Numero de tem para el requerimiento. Descripcin del requerimiento. rea funcional o departamento de la empresa que ser beneficiado con el mismo. Proceso en el que es utilizado. Responsable del requerimiento. Nivel de prioridad generado por el responsable del proyecto. Como ven los temas antes indicados son nicamente los que ha requerido el cliente o parte contratante, por lo cual no se han contemplado las factibilidades de lo requerido versus las capacidades del sistema a implementar. Aspectos a considerar en la parte de consultora versus el requerimiento: Determinar si el sistema es capaz de realizar el requerimiento de forma nativa, esto significa sin tener que realizar un requerimiento de desarrollo adicional. Determinar si el requerimiento no esta en las capacidades nativas del sistemas, establecer si con un desarrollo a la medida se puede acoplar y solventar el requerimiento. Indicar cuando NO se puede realizar un requerimiento por el sistemas, es conveniente colocar las razones para que queden documentadas.
D2.2.INTEGRACINDEPRODUCTOSYSERVICIOS.
Este tema es complejo y se basa en el diagnostico que se realizo previamente antes de iniciar el proyecto. La forma de establecer que tecnologas posee en el momento actual la empresa del cliente y a que nuevas tecnologas desea moverse, es por medio de una evaluacin o diagnostico que permite establecer la situacin previa al proyecto. En este tema es valido citar tecnologas y su respectiva compatibilidad, (hago la salvedad que mi tendencia laboral es sobre herramientas Microsoft por lo que se mencionan los ejemplos) por ejemplo tener entornos donde existen sistemas Unix SCO con dominios MS 2003 es factible su co existencia, pero se deben contemplar los emuladores de terminales que corran sobre las plataformas dominantes. Integrar productos y servicios requiere de un grupo de consultores, no es labor de nica de un gerente de TI o de proyecto, ya que cada producto corre sobre cierta plataforma y esto mismo hace que se necesiten caractersticas especficas en Hardware y Software para su correcto funcionamiento. Cristian Bailey Consultor IT Pg. 114 de 200 MANUAL TCNICO PMI - IT
Un caso de integracin de productos y servicios es por ejemplo las capacidades de un servidor y la cantidad de usuarios a los que prestara servicio, el software que tendr corriendo y los requerimientos de memoria RAM, Este ejemplo integra Hardware necesarios para soportar el Sistema operativo y las aplicaciones o bases de datos que se posicionaran sobre el mismo. Tambin se deben de proyectar los crecimientos a futuro para que en la integracin sean contemplados y no quedaren un nivel lmite muy bajo y generar posibles problemas en un futuro. Integrar como la palabra misma indica, significa buscar las mejores alternativas y compatibilidad de herramientas que generen una solucin para la empresa. Integracin es un trabajo de equipo que se basa en las necesidades o requerimientos, con lo cual se busca entregar una solucin generada en el CASE (Consultara y Anlisis de la Solucin Empresarial). Finalmente integrar productos y servicios significa armar un proyecto y tener establecidos los proveedores sern los responsables de trabajar en equipo para integrar una solucin que satisfaga las necesidades del cliente. Como ven todo esta entrelazado y es vital un tema con el otro, es por ello que al inicio del presente documento cito otros manuscritos que he elaborado que son complementarios para el desarrollo de un proyecto de informtica. Frase: Su equipo integrador de soluciones tecnolgicas.
D2.3.VALIDACIN.
El proceso de validacin es relativo a las dimensiones del proyecto. En los casos que un proyecto es muy grande se recomienda realizar Fases o etapas del mismo para poder realizar la validacin de los trabajos realizados de una forma ms exacta. Como indicamos antes la validacin esta relacionada estrechamente a los requerimientos, es por ello que la matriz de requerimientos permite tener un mapa de los entregables que se estn generando. El proceso de entrega de un requerimiento debe ser correctamente documentado y mencionado en una minuta de los temas que se estn entregando, tambin destacar si se entregan en tiempo y costo estimado previamente. Es recomendable realizar una plantilla o formulario para entregar, con el cual quedara constancia de que la persona que los requiri los revisa y recibe a entera satisfaccin. El formulario tambin deber tener un rea de observaciones para que si no esta satisfecho la persona que recibe se puedan hacer las anotaciones del caso y las correcciones respectivas. Recuerden que al momento de realizar la recepcin de requerimientos de parte del cliente se documentaron y por consiguiente se tiene una mtrica de comparacin de lo que solicito contra lo que se le esta entregando. Es por ello que se debe de adjuntar las copias de esta documentacin al momento de la entrega para que la validacin sea de uno a uno. El proceso de validacin es tan prctico si se documenta correctamente, es por ello que se recomienda anteriormente utilizar las tcnicas de RUP para poder tener el soporte de validacin del caso. Anteriormente se menciona que se debe tener una plantilla de entrega de informes o presentaciones para el comit en donde se pueda resumir las actividades y ser valorizadas, con lo cual se destaca el nivel de avance. MANUAL TCNICO PMI - IT El proceso de validacin es mas bien una disciplina documental que a muchas personas no agrada, pero es elemental para este tipo de procesos de implementacin. Si bien es cierto cada proyecto es diferente, y se pueden contemplar muchos aspectos a entregar, pero es habilidad del gerente o director de proyecto el como desarrolle las mtricas de validacin mas viables y practicas para el mismo.
Pg. 115 de 200
D2.4.ADMINISTRACINDEPLATAFORMASTECNOLGICAS.
Este tema es muy amplio y complejo, ya que una empresa puede tener N plataformas operando entre si internamente o agregarle complejidad al tema y tener que interactuar con plataformas externas como de clientes o proveedores, incluso entidades gubernamentales. Es por ello que este tema se debe contemplar en el CASE antes mencionado, para preveer como se estructurar la administracin de las plataformas, las herramientas de monitoreo que se utilizaran, la definicin de funciones o atribuciones del puesto que ser responsable de esta o estas actividades, porque cabe mencionar que esta es una labor que requiere mas de una persona, lo cual implica temas como capacitacin, y duplicidad de conocimientos. Cuando hablamos de duplicidad de conocimientos nos referimos a que por lo menos 2 personas sean capaz de realizar la misma funcin con lo que se esta garantizado la continuidad. Los planes de contingencia para son vitales en esta parte, por lo que deben estar documentados y probados de forma anticipada en escenarios previstos en las contingencias. Anteriormente se habla de ITIL y COBIT que son metodologas que se relacionan con este tema directamente. ITIL es la metodologa de Service Desk para garantizar el servicio continuo y documentar las fallas y soluciones, as como el control de cambios del caso. Es por ello que es vital contemplar esta parte en la administracin del proyecto. COBIT vela por las buenas prcticas administrativas y de seguridad de la informacin, por lo cual se complementan en relacin a la administracin de plataformas tecnolgicas. No se pretende que se llegue a la implementacin de ITIL o COBIT sistemticamente en un proyecto de este tipo, pero si hace referencia a estas para que puedan extraer las mejores practicas de este tipo de metodologas y as poder tener slidas estructuras administrativas de sus plataformas. El secreto de la administracin de plataformas esta dividido en dos clases de personas que pueden realizar esta actividad: Personal administrativo o sper usuarios que sern capaces de dar soporte a las aplicaciones segn el nivel de escalabilidad al que fueron capacitados para ser soporte de primer nivel y/o ejecutar tareas de administracin de sistema de baja jerarqua. Personal tcnico del rea de TI que ser capaz de brindar soporte de nivel mediano o alto, en quien recaer las responsabilidades del sistema y su correcto mantenimiento preventivo y/o correctivo. Esto resume que las tendencias de administracin de plataformas en informtica hoy en da son delgadas segn el rol de la persona que puede aportar conocimiento.
D2.5.RESTRUCTURACINDELASOLUCIN.
Este tipo de situaciones son poco comunes pero es factible que sucedan, generalmente se dan por dos tipos de motivos ms comunes: El diseo del proyecto no fue revisado adecuadamente por el cliente y se encuentran en una disyuntiva entre lo que el pensaba que recibira y lo que tiene planeado en las actividades del proyecto. Es por ello que se hace nfasis en la correcta revisin de la matriz de requerimientos para el que ambas partes estn completamente satisfechas. La otra razn para hacer cambios en la solucin planteada esta relacionada a circunstancias relacionadas al entorno econmico o poltico, lo cual puede hacer que una empresa realice cambios radicales en plan estratgico, por ende en el proyecto. Es por ello que se debe de contemplar en la parte contractual este tipo de situaciones para que se puedan re definir los proyectos.
Pg. 116 de 200
Es factible este tipo de situaciones que provocan inconformidad entre las partes, por lo cual se debe estar claros que se deber de realizar un alto total en el proyecto, realizar una evolucin nuevamente (esta debe ser como la evaluacin inicial en la que se diagnostico la situacin antes del inicio del proyecto, pero en esta ocasin se reflejara los cambios y la respectiva evolucin del proyecto), el informe deber reflejar la nueva situacin en que esta el proyecto y en base a esta poder generar una proyeccin de cambios respectivos. La recomendacin anterior es poco usual que la siga la gente involucrada en los proyectos, pero en los casos en que se llega a instancias legales es un punto de referencia para argumentos de ambas partes, El reestructurar un proyecto es delicado porque se deber de fijar un nuevo rumbo y por consiguiente un punto de partida. Esto cambia todos los temas de costos y manejo de recursos, por lo cual se recomienda que cuando se tomen este tipo de determinaciones se considere los gastos en que se incurrir. Incluso se puede caer en penalizacin por parte de proveedores debido a circunstancias en las que ellos incurrieron en gastos para esta preparados y anticipados segn el plan inicial del proyecto. Finalmente la restructuracin de la solucin debe ser revisada como se menciona anteriormente y as fijar dar por aceptados ambas partes. En los casos que son requerimientos adicionales que no modifican el proyecto, pero que si adicional actividades se pueden realizar como fases sub siguientes para que no se entorpezca el plan original, siempre y cuando el comit lo acepte como valido.
D2.6.VERIFICACIN.
Este tema es crucial para el proyecto, porque es una actividad que realizan terceros en el proyecto, para dar fe de que los compromisos adquiridos previamente estn generando los resultados o informacin que se requera al inicio del proceso de implementacin. El tema de Validacin que se realiza recomendaciones relacionadas a las mtricas a utilizar en el proceso de entregas y verificacin de resultados para las partes. La verificacin es un proceso minucioso y delicado, hay casos en los que se estn implementando sistemas transaccionales y por consiguiente la variabilidad de la informacin es constante al flujo de operaciones que se trabajan en el sistema. Es por ello que hay ocasiones en las que terceros (auditores financieros o de sistemas) realizan verificacin del correcto resultado de las transacciones realizadas en el sistema. Es un proceso minucioso y por consiguiente las partes deben ser pacientes en el mismo, ya que es la garanta del correcto funcionamiento. Son varios los factores a tomar en consideracin: Preparar Verificacin. Ejecutar Verificacin. Anlisis de resultados y toma de acciones correctivas.
D2.7.GESTINDEENTREGABLES(PRODUCTOSYSERVICIOS).
Son varios los factores a tomar en consideracin: Identificar tem. Establecer sistemas. Controlar cambios de Ingeniera. Ejercer auditorias.
Pg. 117 de 200
Estrechamente relacionado a los procesos de Validacin y verificacin del proyecto, debido a que el plan de trabajo tiene estimados una serie de entregables para determinadas etapas o fases del proyecto en si.
Pg. 118 de 200
La parte mas interesante del proceso de implementacin es la coexistencia de los sistemas antiguos y los nuevos sistemas, por lo cual se debe tener una gestin de tecnologa muy bien estructurada. Esta estructura se genera en el plan estratgico de TI, el cual tiene la visin y misin del departamento ante la empresa y su alineacin en general con el plan estratgico de la empresa. Son varios los factores a tomar en consideracin: Definir estrategia tecnolgica. Definir plan de tecnologa. Negociar Tecnologa.
D2.8.GESTINDETECNOLOGA.
Pg. 119 de 200
Pg. 120 de 200
Dimensin3:ALINEAMIENTOCONELNEGOCIO.
D3.1.DIRECCIONAMIENTOESTRATGICOORGANIZACIONAL.
Esta parte no es un tema que genera la gente del proyecto, debido a que las empresa ya poseen un plan estratgico a X aos el cual se sobre entiende que tiene las empresas revisan cada cierto tiempo. Una organizacin madura posee misin, visin, metas, objetivos y estructura, as como asignaciones para cada una de sus reas funcionales o departamentos. El organigrama refleja la estructura del mismo por consiguiente se puede tener las funciones o atribuciones de cada puesto. El proyecto debe tener como objetivo generar beneficios en el mediano y largo plazo a la empresa, por lo cual el plan estratgico contemplo la necesidad y por ende la inversin. Es por ello que este tema es de referencia para la presentacin del proyecto, ya que resaltara las reas en las que impactara en la organizacin. El termino Impactar es rudo pero es el mas adecuado para este tipo de proyectos debido a que la empresa espera un retorno de la inversin. Es por ello que establecer las fortalezas del proyecto y los cambios o mejoras que estructura a le empresa son de gran importancia para que no se pierda el horizonte del mismo. Son varios los factores a tomar en consideracin: Definir marco estratgico general. Definir estrategias. Definir plan de desarrollo.
Pg. 121 de 200
D3.2.PLANEACINESTRATGICADETI.
El plan estratgico de TI debe anteceder a cualquier proyecto, por lo cual es como el corazn de la estructura del departamento de TI-IS en cualquier empresa. Este plan debe estar alineado al plan estratgico corporativo el cual define el rumbo y rol del la tecnologa de la informacin en la empresa. Este tema se debe desarrollar por independiente y con antelacin, para que los proyectos que se generen en IT tengan un ROI bien enfocado a la estructura central del plan estratgico general de la empresa. Son varios los factores a tomar en consideracin: Alinear plan de TI. Crear / mantener la arquitectura de forma uniforme, esto quiere decir mantener una lnea de plataformas tecnologas que sea ampliamente soportada. Incluir necesidades internas de TI. Elaborar plan de HW y SW base.
Pg. 122 de 200
Pg. 123 de 200
Pg. 124 de 200
INDICADORES Y CUANTIFICACIN DE LA GESTIN DEL PROYECTO.

Este tema es mencionado anteriormente, se puede cuantificar y tomar indicadores de desempeo de un proyecto en base al nivel de ejecucin del mismo, pero mas importante el nivel de entregables decepcionados satisfactoriamente que son al final los tangibles que espera la empresa, como resultado del esfuerzo e inversin. Esta lista debe de definirse desde el inicio para que sean los indicadores de punto donde se encuentra el proceso y el nivel de satisfaccin en los resultados.
Pg. 125 de 200
CAPITULO 5 HERRAMIENTAS PARA LA GESTIN DE PROYECTOS. COMUNICACIN EFICAZ. DEFINICIN DE METODOLOGAS RELACIONADAS. TEMAS RELACIONADOS A LA GESTIN DE PROYECTOS.
Pg. 126 de 200
Existen herramientas que son muy tiles en la administracin tales como Microsoft Project, Mindjet MindManager, Visio, pero primordialmente son los diagramas de Gantt y Pert que permiten monitorear la trayectoria y desempeo del proyecto. ProChainProjectScheduling Es una poderosa herramienta de decisin y programacin de calendarios la cual ayuda en la implementacin de conceptos de mejora en la cadena crtica. Con este software se pueden gestionar los planes de proyectos ms fcilmente, resolver conflictos orientados a la calendarizacin, enfocarse en las tareas claves, seguimiento preciso del estado del proyecto y obtener resultados previsibles en el menor tiempo posible.A travs de esta herramienta se pueden planificar tareas de forma automticas a travs de diagramas de Gantt o modelos PERT, identificar la cadena crtica, eliminar errores y analizar las redes de trabajo, proprocionar ayuda online, generar reportes, entre otras muchas funciones. Manymoon Es una aplicacin sin ningn costo que facilita los procesos de compartir y organizar informacin con el equipo del proyecto. Esta herramienta ayuda a las organizaciones a escapar del caos que puede representar la comunicacin va e-mail, combinando nuevas formas de comunicacin bajo una plataforma de seguridad y administracin que requiere toda empresa. Manymoon es una buena opcin para mantener un monitoreo permanente, as como una constante comunicacin con el project team. Al ser gratis se reducen los costos generados por la adquisicin de software. Adems no requiere de instalacin y tampoco de entrenamiento para su uso y hace una perfecta mancuerna con aplicaciones de Google. LiquidPlanner Esta herramienta completamente basada en web resulta muy interesante, siendo su mayor particularidad la forma bajo la cual aborda la incertidumbre sobre la fecha de trmino de cada tarea y por consecuencia del proyecto en general. Ciertamente, es muy satisfactoria esta caracterstica porque el usuario puede colocar la duracin prevista de una tarea con un mnimo y un mximo. Posteriormente este mnimo y el mximo es usado para establecer el clculo de las probabilidades de que las tareas dependientes tengan un inicio y puedan concluir en una fecha especfica. Cuando el clculo de probabilidades se propaga en cascada, en el cronograma se puede observar muy claramente lo que suceder en el mejor y peor de los casos. Celoxis Esta es una herramienta de administracin de proyectos global basada en web que contribuye a mejorar la colaboracin y dinamizar el manejo de los proyectos, hoja de registro de horario, gastos e incluso procesos de negocio especficos de una organizacin. Para aquellos que tienen poca experiencia en project management, este software ser rpido y fcil de utilizar. Adems incluye todas las herramientas necesarias para manejar en tiempo real los proyectos, tales como diagramas de Gantt, sub tareas, dependencias, restricciones, entre otras. SpectrumProjectManagementSoftware Este programa ayuda a hacer el trabajo de manera ms eficiente y efectiva, proporcionando un proceso fluido y fiable para manejar los flujos de trabajo, la racionalizacin de cada actividad desde su entrada hasta la salida. Asimismo permite el ingreso e intercambio de datos que finalizan las interminables exploraciones del equipo y el administrador de proyecto por conseguir o dar a conocer alguna informacin, mitigando contradicciones en cuanto a sta, a travs de la obtencin de ptimos informes. GeniusProject Es una solucin asombrosa para la administracin de proyectos y mantener la colaboracin en el trabajo, pues va ms all de una simple planeacin, dando cobertura a todas las fases de un proyecto, as como el manejo de todos los documentos relacionados al proyecto. Esta herramienta es una solucin basada 100% en web lo que permite a los miembros del equipo del proyecto tener acceso en tiempo real a la ltima informacin generada. Proporciona una administracin de proyectos escalable, la cual puede ser monitoreada cuando se desee. Del mismo modo, ofrece manejo de tareas, entregables, riesgos, incidentes t reportes de estatus, entre otras mltiples alternativas que ofrece. Wrike
HERRAMIENTAS PARA LA ADMINISTRACIN.
Pg. 127 de 200
Este software para la administracin de proyectos, permite a sus usuarios visualizar fcilmente en qu estado se encuentran sus proyectos y en lo que est trabajando cada uno de los miembros de su equipo. De forma simple le da al usuario la posibilidad de llevar a cabo un profundo seguimiento al avance del proyecto, gracias a la recepcin diaria de un resumen va correo electrnico, captando de esta forma el tiempo dedicado a las tareas y construyendo en tiempo real informes de proyectos transversales. Adems, permite mejorar la Gestin de la Comunicacin, ya que los cambios aplicados en la planificacin se hacen visibles al instante para todos los miembros del equipo. Mingle Es un instrumento de administracin de proyectos giles y de colaboracin para el equipo que proporciona un espacio de trabajo para todo el grupo. Se adapta a la forma de pensar y trabajar de los equipos giles a la vez que soporta varios mtodos giles como XP, Scrum o hbridos. Gracias a su plataforma cada miembro del equipo puede ver lo que estn haciendo los dems integrantes, permitiendo una colaboracin global. TaskJuggler Es una moderna y poderosa herramienta de software libre orientada a administracin de proyectos. A travs del filtrado poderoso y algoritmos de reportes se pueden disear listas de tareas, tablas de usos de recursos, reportes de avances, calendarios de proyectos y declaraciones contables del proyecto. Su enfoque de la planificacin de los proyectos y registro es ms flexible y superior a las herramientas de uso comn para hacer diagramas de Gantt. Adems ofrece la posibilidad de presentar el calendario y avance del proyecto a todos los interesados en el mismo a travs de visualizaciones simples. WBSChartPro Esta aplicacin es utilizada para crear y visualizar proyectos usando el proceso de Work Breakdown Structure o Estructura de Desglose de Trabajo. Un grfico de WBS permite observar la estructura de un proyecto, mostrando cmo est organizado por fases y niveles. Gracias a este software, se pueden plasmar las fases y las subtareas de manera simple, pues permite ver la informacin de horarios, duracin, fecha de inicio, costo, recursos y todo lo necesario para ejecutar una correcta planificacin del proyecto. SimplyProjectOffice Este software proporciona una solucin integrada a travs de muchas mediciones cualitativas en las cuales los Project Managers podran gastar mucho tiempo. La administracin y los reportes de informaciones transitorias pueden hacerse de manera sencilla, lo que desahoga un poco el tiempo del lder de proyecto. Asimismo, le ofrece la posibilidad de monitoreo y manejo de sus propias responsabilidades a todos los miembros del equipo. Adicionalmente ofrece la facilidad de presentar los avances a travs de la web. SPRKnowledgePLAN Es una herramienta de software diseada para ayudar a la planeacin de proyectos. A travs de sta se puede dimensionar efectivamente el tamao de los proyectos, as como estimar el trabajo, recursos, calendario y defectos. Incluso se puede evaluar las fortalezas y debilidades para determinar su impacto sobre la calidad y productividad. Basecamp Frecuentemente, es considerada una ptima herramienta de administracin de proyectos, gracias a su caracterstica que permite hacer listas, compartir archivos, tablero de mensajes, milestones, registro de tiempo, vistas globales del proyecto y comentarios. Adems cuenta con una interface muy ligera que posibilita un manejo ms fcil del software. CAClarityPPMOnDemand Esta herramienta que fue incorporada al mercado apenas en noviembre del 2008 es definida como una opcin Saas (Software as a Service) para Project & Portfolio Manager (PPM). Permite a los lderes de negocios, instituciones de gobierno y organizaciones no lucrativas obtener sencilla y rpidamente la visibilidad que ellos necesitan para mejorar su portafolio, demanda y administracin de proyectos, todo lo que ayuda a alinear mejor a las Ti con los objetivos de negocio de la empresa. Artemis9000 Es una herramienta que sirve para integrar procesos de gestin de proyecto como la planificacin, calendarizacin, agrupacin y reporte. Este programa posibilita el desarrollo de una solucin, de acuerdo a los requerimientos especficos de una organizacin, apoyando la funcionalidad y la tecnologa aplicada dentro de la empresa.
Pg. 128 de 200
@RISKparaProject Esta herramienta ayuda a los administradores de proyectos a darse cuenta de los efectos de la incertidumbre, a comunicar pronsticos realistas acerca del trabajo realizado y a distribuir efectivamente los recursos. Este software utiliza la simulacin Monte Carlo para mostrar todos los posibles resultados de un proyecto, comunicando la probabilidad de que stos sucedan. Se puede determinar qu tareas son ms importantes para luego administrar los riesgos de la manera ms adecuada. ProjectPlanningandManagement Si eres de los que prefiere manejar Excel para la administracin de proyectos, esta plantilla te puede agradar. La plantilla Project Planning and Management fue diseada como una solucin genrica para planificar y administrar cualquier proyecto. Desarrollar el presupuesto mientras se identifican las tareas facilita los procesos para propuestas de casos de negocios, valoracin y financiacin. El progreso puede monitorearse desde la creacin automtica y la actualizacin o desde libros de trabajo remotos participantes. El desempeo del proyecto puede ser monitoreado con las mejores prcticas de Anlisis de Valor Devengado (Earned Value) a travs de todo el ciclo de vida del proyecto. LiveProject Es una aplicacin que mejora MS Project, permitiendo que el usuario y su equipo puedan compartir y colaborar en los planes del proyecto. Sin tener instalado MS Project, los miembros de su equipo tienen la posibilidad de acceder a sus planes compartidos y hacer sugerencias sobre sus trabajos. Las capacidades de filtrado y clasificacin le permiten al equipo obtener informacin en vivo sobre informacin relevante. ScrumDesk Es una herramienta intuitiva de Administracin de Proyectos para el desempeo Scrum (Mtodo gil de Project Management) de equipos de cualquier tamao distribuidos en todo el mundo. Este software no es slo para administradores de proyecto, pues conecta equipos de proyecto y miembros del equipo con los clientes y los gestores. Cualquiera puede identificar fcilmente el estado del proyecto usando informes que muestran las mtricas usadas tpicamente en Scrum. ScrumDesk proporciona en cualquier momento un acceso sencillo a herramientas de colaboracin como mensajera, llamadas por Internet, correos electrnicos, pginas web y sistemas de seguimiento de bugs. PlanBeeprojectmanagementplanningtool Este instrumento sirve para el planeamiento de la Administracin de Proyecto de la ruta crtica. Calcula el comienzo temprano, ltimo comienzo, final temprano, ltimo final, flotador (holgura) e identifica actividades de la ruta crtica. Calcula y resume costos. Los datos se pueden incorporar o importar manualmente de un archivo o del portapapeles. Ofrece una ventana independiente ajustable de tamao que se puede ocultar. Muestra vistas PERT y Gantt del proyecto adems de la vista de hoja de clculo. Se pueden hacer reportes, diagramas de PERT y Gantt que pueden ser impresos o copiados al portapapeles. Tambin genera reportes de pginas Web. MultiProjectPlanner Para aquellos que manejan diferentes proyectos de manera simultnea y a su vez manejan recursos compartidos, esta situacin puede ser un verdadero problema. Es por esto que Multi Project Planner ofrece una lista detallada de las actividades de un proyecto, las cuales son comunes para todos los equipos de trabajo participantes. Su principal ventaja es una descripcin global que presenta tanto la asignacin de recursos como las relaciones mutuas entre las actividades de todos los proyectos y el manejo de stas en una misma ventana. RationalPlanProjectViewer Es un visor de software de gestin de proyectos, constituye una ptima solucin para cualquier persona (desde los involucrados directamente en el proyecto hasta el equipo de trabajadores), para ver los proyectos en detalle. An cuando el gestor de proyectos planifica y controla los mismos de principio a fin realizando los cambios necesarios, hay otras personas que necesitan revisar y tener una visin general de la evolucin de los proyectos hasta su ms mnimo detalle. DataDrill Este software permite que las empresas desplieguen rpidamente las mtricas de un proyecto y el sistema de administracin que entrega informacin crtica a los managers cada vez que lo necesiten. Para sistemas, software e IT managers, DataDrill entrega las mejores prcticas fuera de lo comn, as como una buena configuracin para apoyar las necesidades propias de una compaa. Cristian Bailey Consultor IT Pg. 129 de 200
VIPTASKMANAGER Es un software profesional tipo cliente/servidor para administrar las labores y la colaboracin. Los usuarios autorizados pueden acceder en forma simultnea a la base de datos comn por medio de la red local para ver, agregar, editar y eliminar las tareas de su equipo o personales. Es muy eficiente para planear, programar, compartir, dar seguimiento y reportar tareas, citas, proyectos y todas las actividades relativas a negocios pequeos y organizaciones educativas, gubernamentales o no gubernamentales. XStudio Es una aplicacin de administracin de pruebas que procesa el ciclo de vida completo de los proyectos de QA/Testing de principio a fin. Permite administrar usuarios, requerimientos, especificaciones, SUTs, evaluaciones, planes de prueba, informes de prueba, campaas y defectos. Utilizando la base de datos MySQL como memoria principal, XStudio permite programar o ejecutar campaas de prueba completamente automatizadas o manuales. B-kin Project Monitor es el software de gestin de proyectos online. Caractersticas: Te ayuda a monitorizar proyectos, tareas, personas, perfiles, reas, trabajos, costes, compras, entregables, documentacin, foros, etc. Visin permanentemente actualizada del avance de los proyectos y tareas, Visin permanentemente sobre los impactos sobre costes y el uso de recursos Puedes probar el software de gestin de proyectos gratis. Posee tres versiones: 1.- Versin de prueba. Durante 30 das con todas las caractersticas del software de gestin de proyectos. Puedes crear nuevos proyectos, tareas, personas. 2.- Versin Free. Con limitaciones en varias caractersticas pero con la opcin de utilizar la gestin de proyectos gratis y libre, sin limitacin temporal. 3.- Versin completa. Con todas las caractersticas y servicios disponibles para la gestin de proyectos ms profesional. Esta versin tiene un costo. Curio Curio, es un software til para administradores de proyecto que requieren de una organizacin mucho mas interactiva y visual. Esta herramienta aunque no fue creada para administrar proyectos resulta ser de mucha utilidad pues posee caractersticas tiles en el seguimiento y administracin de proyectos de todos los rubros. Caractersticas: Permite manejar y crear mapas mentales, lluvia de ideas, aplicacin y gestin de proyectos destinados a promover el pensamiento visual en el marco de su innovador entorno virtual pizarra. Puede recordar sus notas, ideas, documentos y, naturalmente, y visualmente. Esta diseado con herramientas que permiten ser ms eficaz y eficiente cuando se trabaja en proyectos. Curio dentro de un proyecto, puede crear un nmero ilimitado de espacios idea en la que puede realizar cualquier cosa en cualquier parte de la pgina. Lluvia de ideas u organizar sus notas con collages de texto, imgenes, enlaces a sitios web, documentos, mensajes electrnicos, pelculas y sonidos. Curio es til tambin para la gestin de proyectos con sus caractersticas tales como un sistema de la fecha de inicio, fecha de vencimiento, a uno o ms recursos, duracin, prioridad, clasificacin, y el porcentaje completo. Dentro de un mapa mental o una lista, puede obtener fechas, la conclusin porcentajes, y los recursos en base a su orden jerrquico.
Mindjet,ProjectManagementJetpack Estos son algunos poderosos recursos incluidos en el Jetpack: Cristian Bailey Consultor IT Pg. 130 de 200
Contiene un libro detallado que ilustra cmo usar MindManager Pro para mejorar la cuenta de su equipo de entrega de proyectos. La gua tambin contiene 15 ejemplos de ruta que le permiten: Documento de definicin de un problema Especificar las necesidades de los proyectos Escribir un plan de negocios Desarrollar un proyecto de Carta Lista de prestaciones del proyecto Y mucho ms ... til para mejorar los resultados de reunin Un ejemplo de un proceso de proyecto con ejemplos para ayudarle a usted y a su equipo al ahorro de tiempo, aumentar la armonizacin y lograr mejores resultados. El proyecto incluye 19 plantillas que le ayudar a: Preparar un caso de negocio Reunir las necesidades de los proyectos Colaborar en el alcance Identificar los riesgos del proyecto y las cuestiones Presentar el estado del proyecto Elaborar listas de control de proyectos Y ms CopperProjectManagementsoftware Lnea de gestin de proyectos, diseada para ayudar a los equipos en la gestin de clientes, los proyectos, tareas, archivos y eventos. Esta herramienta ofrece un calendario dinmico para todo el equipo del proyecto permitiendo la sincronizacin de actividades. Copper est diseado para mantener fcil presupuestacin y automatizado de horarios. Copper puede utilizar el drag'n'drop de tiempo para revisar mltiples proyectos, tareas, personas, volumen de trabajo, los archivos y los presupuestos. Y crear informes personalizados para una mayor flexibilidad. Copper brinda opciones para adaptarse a la mayora de las empresas. Paquetes para recibir cualquier tipo de negocio organizado. ProjectCenterElPoderdelaColaboracininstantnea ProjectCenter le da a su equipo de proyecto del acceso inmediato a una mejor comunicacin y compartir informacin. No es posible cargar el software, no el hardware para la gestin. Basta con hacer clic en su pgina web para el proyecto y comienza a experimentar el poder de la colaboracin instantnea. Es tan intuitivo que la formacin tiene slo una cuestin de minutos. Sea cual sea el tamao o el alcance de sus proyectos, y no importa cun dispersas sus equipos pueden ser, ProjectCenter le proporciona las herramientas para gestionar de manera ms eficiente y con menos problemas a lo largo del camino. Fcil de usar: ProjectCenter es un servicio alojado, no se requiere inversin de ningn hardware o software. Todo lo que necesita es una computadora, un navegador web y una conexin a Internet. Y puesto que la capacitacin dura menos de una hora, los miembros del equipo estar capacitado en unas pocas horas. Est diseada para la Industria de la Construccin: ProjectCenter es configurable, incluye flujos de trabajo especialmente diseado para ingenieros, arquitectos, contratistas y propietarios de edificios. Es personalizable y flexible: ProjectCenter est diseado para permitir a las empresas la libertad para organizar documentos, carpetas y la informacin sin tener que atenerse a plantillas. ProjectCenter permite crear y modificar formas para satisfacer las necesidades especficas de su negocio, y para organizar documentos, carpetas y la informacin en formas que sean ms tiles para sus operaciones. Los usuarios pueden almacenar, gestionar y administrar los datos de una manera que sea ms familiar para ellos, ayudar a los miembros del equipo de ganar eficacia inmediata. MANUAL TCNICO PMI - IT ProjectScheduler8 Su pgina lo presenta como la seleccin profesional para manejo de proyectos. Herramienta para estimaciones mediante COCOMO II. (El sitio permite descargar una versin de prueba con toda la funcionalidad, pero con capacidad limitada en cuanto al tamao del proyecto a estimar.) Enterprise Architect Simplemente la herramienta de bajo costo y amplia funcionalidad, para ingeniera de software. (Todava nos seguimos preguntando cmo le hicieron estos australianos para ofrecerla a ese precio.) Provee algunas funciones tiles (aunque limitadas) para vincular los casos de uso con el manejo de proyectos. Cristian Bailey Consultor IT Pg. 131 de 200
MindManager No es estrictamente una herramienta de manejo de proyectos, pero es muy til para sesiones de lluvia de ideas y categorizacin de conceptos. MSProjectyMSProjectServer Las herramientas de Microsoft para manejo de proyectos. Planner Esta herramienta de manejo de proyectos fue creada originalmente para plataformas Linux y Unix por Richard Hult y Mikael Hallendal, de Imendio. Actualmente es la herramienta de GNOME para manejo de proyectos en una gama ms amplia de plataformas: Linux, Solaris, HP-UX, BSD y Darwin de Apple. Primavera Herramientas de manejo de proyectos ampliamente utilizadas en varias ramas de ingeniera, y especialmente en la industria de la construccin.
SIGLAS PMI
ACWP Actual Cost of Work Preformed (Costo Real de Trabajo Realizado) AD Activity Description (Descripcin de Actividad) AFActual Finish date (Fecha Real de Terminacin) BAC Budget at Completion (Presupuesto al Terminar) CCB Change Control Board (Comit de Control de Cambios) CPI Cost Performance index (Indice de Desempeo de Costos) CPM Critical Path Method (Mtodo de la Ruta Crtica) DD Data Date (Fecha de Corte) DU DUration (DUracin) EACEstimateAtCompletion (Estimado al Terminar) EF Early Finish date (fecha de Terminacin Temprana) ES Early Start date (Fecha de Comienzo Temprana) EV Earned Value (Valor Ganado o devengado) EVM Earned Value Management (Administracin de Valor Devengado) FS Finish-to-Start (Comienzoa-Fin) MANUAL TCNICO PMI - IT GERT Graphical Evaluation and Review Technique (Tcnica de Revisin y Evaluacin Grfica) LF Late Finish date (Fecha de Terminacin Tarda) MPM Modern Project Management (Administracin de Proyectos Moderna) PDM Precedence Diagramming Method (Mtodo de Diagramacin de Precedencias)
Pg. 132 de 200
PERT Program Evaluation and Review Technique (Tcnica de Revisin y Evaluacin de Programas) PMBOK Project Management Body of Knowledge (Cuerpo de Conocimientos de la Administracin de Proyectos) PMIS Project Management Information System (Sistema de informacin de la gerencia de proyecto QC Quality Control (Control de Calidad) RAM Responsibility Assignment Matrix (Matriz de Responsabilidad) SOW Statement Of Work (Declaracin de Trabajo) TQM Total Quality Management (Administracin de Calidad Total) TSTarget Start date (Fecha de Comienzo de la Meta) WBS Work Breakdown Structure (Estructura de Desglose de Trabajo)
CONCEPTO DE RUP
RUP es un proceso para el desarrollo de un proyecto de un software que define claramente quien, cmo, cundo y qu debe hacerse en el proyecto. Como 3 caractersticas esenciales est dirigido por los Casos de Uso: que orientan el proyecto a la importancia para el usuario y lo que este quiere, est centrado en la arquitectura: que Relaciona la toma de decisiones que indican cmo tiene que ser construido el sistema y en qu orden, y es iterativo e incremental: donde divide el proyecto en mini proyectos donde los casos de uso y la arquitectura cumplen sus objetivos de manera ms depurada. RATIONAL UNIFIED PROCESS = RUP El ciclo de vida de RUP RUP divide el proceso en 4 fases, dentro de las cuales se realizan varias iteraciones en nmero variable segn el proyecto y en las que se hace un mayor o menor hincapi en los distintas actividades. En las iteraciones de cada fase se hacen diferentes esfuerzos en diferentes actividades: Inicio: Se hace un plan de fases, se identifican los principales casos de uso y se identifican los riesgos. Se define el alcance del proyecto Elaboracin: se hace un plan de proyecto, se completan los casos de uso y se eliminan los riesgos Construccin: se concentra en la elaboracin de un producto totalmente operativo y eficiente y el manual de usuario Transicin: se Instala el producto en el cliente y se entrena a los usuarios. Como consecuencia de esto suelen surgir nuevos requisitos a ser analizados.
CONCEPTO DE ITIL
Introduccin a ITIL ITIL son las siglas de una metodologa desarrollada a finales de los aos 80s por iniciativa del gobierno del Reino Unido, especficamente por la OGC u Oficina Gubernativa de Comercio Britnica (Office of Goverment Comerce). Las siglas de ITIL significan (Information Technology Infrastructure Library) o Librera de Infraestructura de Tecnologas de Informacin. Esta metodologa es la aproximacin ms globalmente aceptada para la gestin de servicios de Tecnologas de Informacin en todo el mundo, ya que es una recopilacin de las mejores prcticas tanto del sector pblico como del sector privado. Estas mejores practicas de dan en base a toda la experiencia adquirida con el tiempo en determinada actividad, y son soportadas bajo esquemas organizacionales complejos, pero a su vez bien definidos, y que se apoyan en herramientas de evaluacin e implementacin. Cristian Bailey Consultor IT Pg. 133 de 200
El objetivo de usar ITIL en Managed Services ITIL como metodologa propone el establecimiento de estndares que nos ayuden en el control, operacin y administracin de los recursos (ya sean propios o de los clientes). Plantea hacer una revisin y reestructuracin de los procesos existentes en caso de que estos lo necesiten (si el nivel de eficiencia es bajo o que haya una forma mas eficiente de hacer las cosas), lo que nos lleva a una mejora continua. Otra de las cosas que propone es que para cada actividad que se realice se debe de hacer la documentacin pertinente, ya que esta puede ser de gran utilidad para otros miembros del rea, adems de que quedan asentados todos los movimientos realizados, permitiendo que toda la gente este al tanto de los cambios y no se tome a nadie por sorpresa. En la documentacin se pone la fecha en la que se hace el cambio, una breve descripcin de los cambios que se hicieron, quien fue la persona que hizo el cambio, as como quien es el que autorizo el cambio, para que as se lleve todo un seguimiento de lo que pasa en el entorno. Esto es ms que nada como mtodo con el que se puede establecer cierto control en el sistema de cambios, y as siempre va a haber un responsable y se van a decir los procedimientos y cambios efectuados.
CONCEPTO DE COBIT
COBIT 4.0 (Control OBjectives for Information and related Technology | Objetivos de Control para tecnologa de la informacin y relacionada) Es el modelo para el Gobierno de la TI desarrollado por la Information Systems Audit and Control Association (ISACA) y el IT Governance Institute (ITGI). Tiene 34 objetivos nivel altos que cubren 215 objetivos de control clasificados en cuatro dominios: El plan y Organiza, Adquiere y Pone en prctica, Entrega y Apoya, y Supervisa y Evala. Enfatiza el cumplimiento normativo, ayuda a las organizaciones a incrementar el valor de TI., apoya el alineamiento con el negocio y simplifica la implantacin del COBIT. Esta versin no invalida el trabajo efectuado con las versiones anteriores del COBIT, sino que mejora el trabajo hecho. Representa los esfuerzos de literalmente cientos de expertos de voluntario de en el mundo entero. Lo ofrecen como un descargado libre (gratis) de www.isaca.org/cobit, y, como una ventaja especial para miembros ISACA, est disponible a miembros exclusivamente durante un perodo de dos semanas. El 16 de diciembre, el descargado se har disponible pblicamente. Es un marco de gobernacin TI que permite a gerentes acortar el hueco entre exigencias de control, cuestiones tcnicas y riesgos de negocio. COBIT permite el desarrollo claro de poltica y la prctica buena para el control de TI en todas partes de organizaciones. La ltima versin del ITGI - COBIT 4.0 - acenta el cumplimiento regulador, ayuda a organizaciones a aumentar el valor logrado de TI, permite la alineacin y simplifica la puesta en prctica del marco COBIT. Esto no invalida el trabajo hecho basado en las versiones ms tempranas de COBIT, pero en cambio puede ser usado realzar el trabajo ya hecho basado sobre aquellas versiones ms tempranas. Cuando actividades principales son planeadas para iniciativas de gobernacin TI, o cuando una revisin y reparacin del marco de control de la empresa es esperada (prevista), le recomiendan comenzar fresco con COBIT 4.0. COBIT 4.0 actividades de regalos en una manera ms dinamizada y prctica tan la mejora continua de la gobernacin TI es ms fcil que alguna vez para alcanzar. Esta nueva versin refleja la armonizacin aumentada con otras normas detalladas, el nfasis mayor sobre la gobernacin TI, el dinamizar de conceptos y lengua, y el anlisis detallado de conceptos de mtrico, entre otras mejoras. El nuevo volumen, consistiendo en ms de 200 pginas, incluye una descripcin ejecutiva, el marco, el contenido principal (el control de alto nivel objetivos de control objetivos, detallados, directrices de direccin y el modelo de madurez) para cada uno de los 34 procesos, y varios apndices. Cristian Bailey Consultor IT Pg. 134 de 200 MANUAL TCNICO PMI - IT
PARA QU SIRVE Independientemente de la realidad tecnolgica de cada caso concreto, COBIT determina, con el respaldo de las principales normas tcnicas internacionales, un conjunto de mejores prcticas para la seguridad, la calidad, la eficacia y la eficiencia en TI que son necesarias para alinear TI con el negocio, identificar riesgos, entregar valor al negocio, gestionar recursos y medir el desempeo, el cumplimiento de metas y el nivel de madurez de los procesos de la organizacin. Proporciona a gerentes, interventores, y usuarios TI con un juego de medidas generalmente aceptadas, indicadores, procesos y las mejores prcticas para ayudar a ellos en el maximizar las ventajas sacadas por el empleo de tecnologa de informacin y desarrollo de la gobernacin apropiada TI y el control en una empresa. Proporciona ventajas a gerentes, TI usuarios, e interventores. Los gerentes se benefician de COBIT porque esto provee de ellos de una fundacin sobre cual TI las decisiones relacionadas e inversiones pueden estar basadas. La toma de decisiones es ms eficaz porque COBIT ayuda la direccin en la definicin de un plan de TI estratgico, la definicin de la arquitectura de la informacin, la adquisicin del hardware necesario TI y el software para ejecutar una estrategia TI, la aseguracin del servicio continuo, y la supervisin del funcionamiento del sistema TI. TI usuarios se benefician de COBIT debido al aseguramiento proporcionado a ellos si los usos que ayudan en la reunin, el tratamiento, y el reportaje de informacin cumplen con COBIT ya que esto implica mandos y la seguridad es en el lugar para gobernar los procesos. COBIT beneficia a interventores porque esto les ayuda a identificar cuestiones de control de TI dentro de la infraestructura TI de una empresa. Esto tambin les ayuda a corroborar sus conclusiones de auditoria. La misin COBIT es " para investigar, desarrollar, hacer pblico y promover un juego autoritario, actualizado, internacional de objetivos de control de tecnologa de informacin generalmente aceptados para el empleo cotidiano por directores comerciales e interventores. " Los gerentes, interventores, y usuarios se benefician del desarrollo de COBIT porque esto les ayuda a entender sus sistemas TI y decidir el nivel de seguridad (valor) y control que es necesario para proteger el activo de sus empresas por el desarrollo de un modelo de gobernacin TI.
CONCEPTO DE PMI
Este documento reemplaza El Cuerpo de Conocimiento de la Administracin de Proyectos de PMI (PMBOK) documento que fue publicado en 1987. Para asistir a los usuarios de este documento que puedan estar familiarizados con su predecesor, hemos resumido aqu las principales diferencias 1. Hemos cambiado el ttulo para enfatizar que este documento no es el PMBOK. El documento de 1987 defina al PMBOK como todos los tpicos, reas de materia y procesos intelectuales que estn involucrados en las prcticas de principios administrativos sanos a los ...proyectos. Claramente se observa que un solo documento nunca contendr la totalidad del PMBOK. 2. Hemos reescrito completamente la seccin del Marco Terico. La nueva seccin consiste de tres captulos: Introduccin, que fija el propsito del documento y define de manera extensa los trminos proyecto y administracin de proyectos. El Contexto de la Administracin de Proyectos, que cubre el contexto en el que operan los proyectos el ciclo de vida del proyecto, las perspectivas de los partidos interesados, influencias externas, y habilidades claves de la administracin general. Los Procesos Administrativos de los Proyectos, que describe como los elementos varios de la administracin de proyectos se interelacionan. 3. Hemos desarrollado una definicin revisada de proyecto. Queramos una definicin que era tanto inclusiva (no debera ser posible identificar cualquier empresa generalmente considerada como un proyecto que no llene la definicin) y exclusiva (no debera ser posible identificar cualquier empresa que satisfaga la definicin y que generalmente no se piensa como proyecto). Se revisaron muchas de las definiciones de proyecto en la literatura existente y se encontraron todas insatisfactorias de alguna manera. La nueva definicin es motivada por las caractersticas nicas de un proyecto: un proyecto es una tarea temporal desarrollada para crear un producto o servicio nico.
Pg. 135 de 200
Hemos desarrollado una nueva vista del ciclo de vida del proyecto. El documento de 1987 defina las fases de proyecto como subdivisiones del ciclo de vida del proyecto. Hemos reordenado estas relaciones y definido el ciclo de vida del proyecto como una coleccin de fases cuyos nmeros y nombres estn determinados por las necesidades de control de la organizacin ejecutora. 5. Hemos cambiado los nombres de las principales secciones de funcin a rea de conocimiento. El termino funcin ha sido frecuentemente malentendido como un elemento de la organizacin funcional. El cambio de nombre deber de eliminar este malentendido. 6. Reconocemos formalmente la existencia de una novena rea de conocimiento. Ha existido un consenso amplio durante algn tiempo de que la administracin de proyectos es un proceso integrativo. El Captulo 4, Administracin de la Integracin de Proyecto, reconoce la importancia de este tema. 7. Hemos agregado la palabra proyecto al ttulo de cada rea de conocimiento. Aunque esto pueda parecer redundante, ayuda a clarificar el alcance de este documento. Por ejemplo, La Administracin de Recursos Humanos cubre solo esos aspectos de la administracin de recursos humanos que son nicos o casi nicos al contexto de proyectos. 8. Hemos escogido describir las reas de conocimiento en trminos de sus componentes de proceso. La bsqueda de un mtodo consistente de presentacin nos ha llevado a reestructurar completamente el documento de 1987 en 37 procesos administrativos de proyectos. Cada proceso esta descrito en trminos de sus entradas, salidas, herramientas y tcnicas. Las entradas y salidas son documentos (e.g., una declaracin de alcance) o tems documentables (e.g., dependencias de actividades). Las herramientas y tcnicas son los mecanismos aplicados a las entradas para crear las salidas. Adems de su simplicidad fundamental, esta aproximacin ofrece otros beneficios, a saber: Enfatiza las interacciones entre las reas de conocimiento. Las salidas de un proceso se convierten en entradas para otro. La estructura es flexible y robusta. Cambios en conocimientos y prcticas pueden ser acomodados agregando un nuevo proceso, cambiando las secuencias de procesos, subdividiendo un proceso, o al agregar material descriptivo dentro de un proceso. Los procesos estn en el ncleo de otros standards. Por ejemplo, los standards de calidad de la Organizacin Internacional de Standards (serie ISO 9000) se basan en la identificacin de los procesos de negocios. 9. Agregamos algunas ilustraciones. Cuando se trata de estructuras de desglose de trabajo, diagramas de red, y curvas S, una imagen vale ms que mil palabras. 10. Hemos reorganizado el documento de manera significativa. La siguiente tabla provee una comparacin entre los encabezados del documento de 1987 con este:
4.
Nmero y Nombre de 1987 0. Standards PMBOK
Nmero y Nombre de 1996 B. Evolucin de Una Gua al Cuerpo de Conocimientos de la Administracin de Proyectos de PMI 1. Introduccin (definiciones bsicas) 2. El Contexto del Proyecto (ciclos de vida)
1. Marco Terico: El Raciocinio
2. Marco Terico: Una Resea
1. Porciones varias 2. Porciones varias 3. Porciones varias 4. Administracin de Integracin del Proyecto MANUAL TCNICO PMI - IT
3. Marco Terico: Un Modelo Integrativo
3. Procesos Administrativos de Proyectos
4. Glosario de Trminos Generales A. Administracin del Alcance B. Administracin de la Calidad Cristian Bailey Consultor IT
IV. Glosario 5. Administracin Proyecto del Alcance del
8. Administracin de la Calidad del Pg. 136 de 200
Proyecto C. Administracin del Tiempo D. Administracin de Costos E. Administracin de Riesgos F. Administracin del Recurso Humano G. Administracin Contratos/Procuracin H. Administracin de Comunicaciones de 6. Administracin de Tiempo del Proyecto 7. Administracin de Costos del Proyecto 11. Administracin de Riesgos del Proyecto 9. Administracin del Recurso Humano del Proyecto 12. Administracin del Procuramiento del Proyecto 10. Administracin de Comunicaciones del Proyecto las
11. clasificar a ha sido removido de la lista de propsitos. Tanto este documento como la versin de 1987 proveen una estructura para organizar el conocimiento de la administracin de proyectos, pero ninguna es particularmente til como una herramienta de clasificacin. Primero, los tpicos incluidos no estn completos no incluyen prcticas innovadoras o inusuales. Segundo, muchos elementos tienen relevancia en ms de un rea de conocimiento o proceso de tal manera que las categoras no son nicas. El Marco de la Administracin de Proyectos INTRODUCCIN El cuerpo de conocimiento de proyectos (PMBOK) es un trmino inclusivo que describe la suma de los conocimientos dentro de la profesin de administracin de proyectos. Como en otras profesiones tales como: medicina, abogaca, contadura, el cuerpo del conocimiento recae sobre profesionales y acadmicos que aplican ese conocimiento y lo avanzan. El PMBOK entero incluye conocimiento probado y prcticas tradicionales que se aplican ampliamente, adems del conocimiento e innovaciones de prcticas avanzadas que han visto un uso ms limitado.
CONCEPTOS DE COMUNICACIN EFICAZ

En esta parte se describe como crear un proceso de comunicacin eficaz con los clientes, ya que cada usuario de TI es un cliente, es por ello que se visualiza al personal de TI como un vendedor de servicios, por lo cual debe generar satisfaccin para sus usuarios.
EL ARTE DE ESCUCHAR
Nos gusta mas hablar que escuchar.
Casi todos estaramos dispuestos a admitir que es mejor hablar que escuchar. Hablar es seal de autoridad y actividad, mientras que escuchar parece ser un empeo pasivo. El hecho es que se ha demostrado que el escuchar es algo activo, es trabajo mental. Hay pruebas que han demostrado que se produce una fluctuacin en nuestros patrones de ondas cerebrales, aumenta la temperatura y el corazn late con ms rapidez cuando estamos escuchando con atencin.
No somos tan buenos escuchas como creemos.

MANUAL TCNICO PMI - IT Estas pruebas tambin han demostrado que no somos tan buenos escuchas como creemos serlo; la mayora escuchamos apenas con un 20 % de eficiencia. No podremos tener xito como vendedores si solo escuchamos una quinta parte de lo que se est diciendo. Las ventas efectivas requieren destrezas efectivas en el arte de escuchar. El saber escuchar es la clave del arte de vender que nos permite determinar lo que el cliente desea y necesita. Si no dominamos este arte no podemos poner en prctica nuestras otras destrezas.
No el que ms habla es el que ms vende.
Pg. 137 de 200
Antiguamente se pensaba que los vendedores deban ser personas muy hbiles y diestras en el arte de hablar, no en el de escuchar. La famosa rutina del vendedor con gran habilidad para hablar, que por no saber escuchar, se ve metido en un enredos que le estn bien merecidos por no saber escuchar a su cliente.
El peligro de escuchar demasiado.

Por otra parte, si escuchamos demasiado y no hablamos lo suficiente, podemos perder el control de la entrevista de ventas. Es frecuente evaluar la capacidad de escuchar en trminos de conversaciones de final abierto. En nuestra actividad de vendedores, no solemos participar en este tipo de conversaciones; tenemos, en cambio, un propsito que nos empeamos en alcanzar: determinar si nuestro producto cumple con las necesidades del cliente. Por lo tanto, tenemos que ser directos: esta es una responsabilidad que constituye un reto.
Obstculos que impiden hablar.

Para hacer an mayor el reto de este proceso, existen varios obstculos que impiden escuchar con eficiencia. Es posible que la interferencia del medio ambiente escape a nuestro control, aunque, ms adelante en la pelcula, vemos cmo el vendedor aprovecha esta interferencia. Sin embargo, s podemos controlar las distracciones que surgen de nosotros mismos. Una de estas distracciones es la atencin dividida. Al tratar de hacer demasiadas cosas a un tiempo, nos colocamos y colocamos al cliente en una posicin injusta.
Nosotros mismos podemos ser un obstculo.

Hay otro obstculo que puede tener su origen en nosotros mismos; cuando hablamos con nosotros mismos comprometemos nuestra capacidad de escuchar al cliente. Es evidente que debemos hacer planes anticipados, pero debemos evitar hacerlos mientras nos est llegando informacin importante. Esto lo vemos en la pelcula, cuando el vendedor pierde por completo lo que el cliente trata de decir.
El temor al fracaso.
Uno de los peores obstculos para poder escuchar es el temor al fracaso. Al tratar de formarnos una vaga idea de las preocupaciones del cliente o escucharlas slo a medias, estamos buscando precisamente el fracaso que queremos evitar.
Donde se inicia el proceso activo de escuchar con eficiencia.

El proceso activo de escuchar comienza incluso antes de que nos encontremos con el cliente. Antes de efectuar una visita debemos preparar la informacin de base de la cuenta. Es necesario prever preguntas y objeciones que podamos esperar del cliente y tener preparadas las posibles respuestas para esas objeciones.
Como preguntar.
Al saludar al cliente, debemos procurar formarnos una idea global de su situacin hacindole preguntas abiertas de carcter general. Las respuestas nos darn un contexto global dentro del cual podremos profundizar ms adelante para obtener detalles. MANUAL TCNICO PMI - IT
La importancia del contacto visual y el tomar notas.

Mientras escuchamos al cliente conviene mantener el control visual y ofrecer confirmacin verbal y no verbal de que, de hecho estamos escuchndolo. Incluso si el cliente habla sin cesar, es importante seguir escuchando. Tal vez seamos los beneficiarios de palabras "inadvertidas" que pueden ofrecernos un ngulo para una venta exitosa. Siempre podremos volver a encauzar una conversacin que se desve del punto, mediante una pregunta gua.
Pg. 138 de 200
A veces conviene tomar notas, aunque stas deben limitarse a hechos y cifras. El confiar demasiado en las notas puede interferir en nuestra capacidad de escuchar con eficiencia y puede constituir una distraccin innecesaria para las dos partes.
Debemos descubrir lo que el cliente realmente quiere.

Es frecuente que los clientes expresen en forma verbal lo que creemos que quieren y no lo que realmente quieren. En la pelcula; Un vendedor debe darse cuenta de que los clientes tienen problemas para expresar qu es lo que necesitan y lo que desean y puede llevarlos a ver la casa que sabe que les va a gustar. Al escuchar y observar atentamente al cliente podemos ayudar a reconocer un mensaje no expresado y a solucionar el problema.
La estrategia de aprovechar las interrupciones.

Claro que cualquier interrupcin puede ser una molestia a menos que la aprovechemos como una oportunidad para descubrir una informacin esencial para una venta exitosa. El vendedor de la pelcula puede sacar ventaja de una interrupcin mediante "la imaginacin". Esta tcnica consiste en recopilar informacin la informacin reunida durante la preparacin de la visita y durante la entrevista misma, para lograr una imagen coherente de la situacin del cliente. Una vez logrado esto llega el momento de buscar detalles que nos puedan ayudar a cerrar la venta. Por ltimo, tenemos que darle al cliente nuestra informacin de retorno para determinar si los datos que hemos reunido son correctos. A esto se le conoce como proceso de verificacin y sirve para confirmarle al cliente que lo hemos estado escuchando con atencin.
En resumen.
Hemos aprendido que el proceso de escuchar se compone de tcnicas sencillas: planes anticipados, toma de notas, preguntas adecuadas en el momento adecuado, y estar atentos a lo que escuchamos, verificando los datos mediante la informacin de retorno. El hbito de saber escuchar produce dividendos. A cambio de esto obtenemos informacin, confianza y respeto mutuos.
ALGUNOS DATOS GENERALES El arte de escuchar entre los griegos.

Los buenos hbitos del arte de escuchar se han reconocido durante siglos como algo indispensable para el xito; de hecho, Scrates se quej alguna vez de que sus jvenes alumnos tenan muy malas cualidades como oyentes. Muchos de los problemas son el resultado de que pensamos mucho ms rpido de lo que hablamos.
La velocidad con la que hablamos y pensamos.

Se ha dicho que la mayora de nosotros hablamos a una velocidad de cerca de 125 palabras por minuto. Sin embargo nuestra velocidad de pensamiento es 4 veces mayor. Es evidente que esto nos deja mucho tiempo libre mientras alguien nos habla. La forma en que utilicemos este tiempo determina el hecho de que seamos diestros o no en el arte de escuchar. Si reconocemos, como vendedores, que la capacidad de escuchar es una destreza que se adquiere, al igual que otras destrezas en el campo de la ventas, podremos utilizar ese tiempo para concentrar y ampliar nuestros esfuerzos por obtener una venta exitosa. Podremos comprobar que al unir la capacidad de escuchar con nuestra habilidad para prever, observar, interrogar; suministrar informacin de retorno y resolver problemas, constituir nuestra mejor garanta de xito.
PLANIFICACION DE LA ENTREVISTA CON EL CLIENTE PARA ESCUCHAR PROFESIONALMENTE
Pg. 139 de 200
Para elaborar planes anticipados tenemos que saber...

Antes de visitar a un cliente, es necesario plantearnos varias preguntas sobre las circunstancias de la visita:
1. Cules son los hechos especficos de la entrevista ?

Debemos averiguar cuanto sea posible acerca de las operaciones del cliente; el volumen de sus negocios, el tiempo que lleva trabajando y sus planes para desarrollo y expansin. Si se trata de un cliente establecido, debemos estar enterados de nuestra historia mutua. Si se trata de una nueva cuenta, debemos averiguar con otros para obtener datos sobre el cliente.
2. Qu sabe el cliente de mi producto o servicio ?

No queremos que un cliente bien informado crea que estamos adoptando una posicin paternalista, ni queremos que un cliente mal informado piense que le estamos pidiendo que sepa ms acerca de nosotros. En cualquiera de los dos casos, es posible que el cliente se sienta intimidado y a disgusto. Debemos preparar la entrevista teniendo en cuenta el nivel de conocimientos del cliente para poder dedicar nuestro tiempo a escuchar y a resolver problemas. Tambin debemos estar preparados y tener las respuestas para preguntas previstas sobre costos, formas de pago y otras reas relacionadas con nuestro producto o servicio.
3. Qu actitud tiene el cliente hacia mi producto o servicio?

Ha tenido malas experiencias previas con mi producto o con otros productos similares? Con mi compaa? Estas son preguntas que tenemos que plantearnos antes de visitar al cliente; del contrario, se nos ir la mayor parte del tiempo oyendo una diatriba y no estaremos preparados para hacer frente a las objeciones del cliente.
4. Cul ser la actitud del cliente hacia m?

Hay muchas razones por las que el cliente puede tener una actitud negativa hacia nosotros. Puede ser por una experiencia previa con alguna persona de nuestra compaa que la ha dejado una mala impresin al cliente. Puede ser tambin porque el cliente tiene prejuicios contra nosotros por razones menos lgicas. En cualquier caso, es absurdo enfrentarse a una situacin negativa sin tener una estrategia preparada.
5. Qu antecedentes o experiencias compartidas podemos tener en comn?

Esta es una informacin muy til que nos puede preparar el terreno para un interrogatorio y un anlisis de carcter general. Un tipo de "charla" suele ser til par abrir puertas.
6. Cul ser la tnica de la entrevista?

Debemos estar seguros de tener informacin sobre situaciones previas. Tambin debemos procurar conocer el estado actual y la posicin financiera del cliente para poder manejar estos factores e impedir que se conviertan en obstculos. MANUAL TCNICO PMI - IT Existe una correlacin directa entre la elaboracin de los planes y la capacidad de escuchar, aunque esta relacin pueda ser difcil de reconocer. Una elaboracin previa de planes efectivos nos impide quedar atrapados de improviso y tener que inventar una solucin sobre la marcha. Al prepararnos, lograremos dos cosas: en primer lugar, determinaremos la direccin que deseamos y, en segundo lugar, nos habremos permitido dedicar nuestro tiempo a escuchar al cliente. Esto aumenta nuestras probabilidades de poder detectar las verdaderas necesidades del cliente.
OBSERVACION
Pg. 140 de 200
La pelcula se refiere a la observacin como a una " extensin en la necesidad de escuchar". Se nos ha dicho que hay dos clases de comunicacin: la verbal y la visual. Al escuchar acumula comunicacin verbal y la observacin es el instrumento que nos permite acumular la comunicacin no verbal. Si vemos que el cliente se siente incmodo con un determinado estilo de interrogar debemos empezar a entrar ms a fondo para descubrir el verdadero problema del cliente. La observacin va ms all de la conversacin real. Al observar el lugar donde el cliente desarrolla sus negocios, podemos enterarnos de muchas cosas: de la situacin del negocio, de la capacidad del cliente para pagar y de su autoridad para comprar. Todos estos hechos son indispensables tanto para cerrar una venta como para determinar la orientacin de la entrevista. En la pelcula, vimos como Al, el vendedor, identificaba varios de los problemas de su cliente poniendo a prueba la "extensin de la capacidad de escuchar". El tomar notas, si no se exagera, puede ser til. Esto nos preparar con la opcin de que si el cliente no responde a nuestro primer abordaje, podemos cambiar de rumbo diciendo, " a propsito he visto que..." Por lo general el cliente responde a este tono de inters personal.
EL INTERROGATORIO
Como lo hemos visto en la pelcula, el interrogatorio es parte importante del arte de escuchar con efectividad. El hacer la pregunta adecuada en el momento preciso nos permitir determinar las verdaderas necesidades del cliente. Hay cuatro clases de preguntas que debemos hacer en orden cronolgico para obtener informacin sobre las necesidades del cliente. 1. Las preguntas de carcter general que establecen nuestro inters por la situacin del cliente. 2. Las preguntas de carcter especfico que sirven para determinar la forma en que el cliente piensa utilizar nuestro producto o servicio y nos suministra datos exactos. 3. Preguntas inquisitivas que determinan las necesidades. Una pregunta inquisitiva, es, por ejemplo, Desea usted algo similar al modelo B2000?" o Le interesara este material si se pudiera conseguir en verde? 4. Preguntas orientadoras que llevan al cliente a darse cuenta de sus propias necesidades. Estas preguntas suelen expresarse como No es excepcional el funcionamiento de esta mquina? Debemos recordar que el hacer preguntas, no importa qu tan hbilmente, es intil a menos que se combine con una buena capacidad de escuchar. Debemos concentrarnos en descubrir cul es "el mensaje secreto" del cliente y solo podremos determinar esto si prestamos mucha atencin a lo que se nos dice.
INFORMACION DE RETORNO
La informacin de retorno, conocida tambin como "proceso de verificacin" ha sido muy efectiva dentro del proceso de saber escuchar. Son varias sus ventajas: Le garantiza al cliente que lo hemos estado escuchando y que lo entendemos. En la mayora de los casos el cliente se siente honrado de que hayamos estado atentos y responder en la misma forma. 2. Nos garantiza que poseemos datos correctos y le permite al cliente corregir cualquier malentendido. 3. Permite ventilar ideas para llegar a un entendimiento mutuo. Es frecuente encontrar que el suministrar informacin de retorno da pie para analizar otros aspectos. Este proceso de verificacin da pie para analizar otros aspectos. Este proceso de verificacin suele abrir paso a nuevas ideas y nuevos anlisis as como a otras posibles necesidades que el vendedor puede satisfacer. Pg. 141 de 200
4. La informacin de retorno evita el sndrome de "a que usted no lo puede hacer mejor. "En este sndrome, se crea un clima de competencia entre el cliente y el vendedor que, en lugar de escuchar a otro, llegan al punto en que ninguno de los dos se benefician. Mediante la informacin de retorno podemos mantener la conversacin dentro de un tono comercial. La retroalimentacin, junto con la preparacin anticipada, la habilidad de observacin y la capacidad de interrogar y escuchar, nos ofrecen la oportunidad de comprender las necesidades y problemas del cliente. De ah en adelante tenemos que convertirnos en solucionadores de problemas.
BARRERAS QUE IMPIDEN ESCUCHAR EN FORMA EFECTIVA

En la pelcula vimos cmo varias formas de interferencia fsica por distraernos e impedirnos escuchar en forma efectiva a nuestros clientes. El ruido, la confusin y el cansancio pueden limitar en alto nuestra concentracin. Sin embargo, las barreras mentales son ms graves. En Better Business Comunication se encuentran cinco obstculos que impiden escuchar con atencin y que surgen de nosotros mismos:
Barreras que impiden escuchar con eficiencia durante la venta:

1. La indiferencia: Muchas veces pensamos que lo que el cliente dice no tiene importancia y dejamos de escuchar mientras nuestras mentes divagan. Esto trae dos desventajas evidentes: en primera, el cliente puede decir algo de veras importante mientras estamos distrados y, en segundo lugar, y an ms importante, nos estamos volviendo escuchas perezosos y ste hbito puede ser difcil de erradicar despus. La indiferencia al escuchar no tiene excusa; significa que somos indiferentes a la venta y, de ser as, estamos en el lugar equivocado.
2. La impaciencia: puede ser ms comprensible, aunque no deja de ser un problema igualmente grave. Nos
impacientamos con un cliente lento, o uno que no cesa de hablar, y nuestras ideas empiezan a adelantarse a la conversacin. El riesgo aqu est en que no podemos pasar por alto ningn indicio importante que pudiera ayudarnos a la venta. Por lo tanto, debemos observar una estricta disciplina y concentrarnos en lo que diga el cliente, aunque nunca termine de decirlo.
3. El prejuicio: Si permitimos que un prejuicio racial o de otro tipo interfiera con nuestra capacidad de escuchar, estamos en el lugar equivocado y debemos hacer planes para cambiar de trabajo tan pronto como sea posible. Pero si permitimos que aparezcan prejuicios como la forma de hablar del cliente, sus actitudes o su compaa, tenemos que aprender a controlarlos. Al pensar en el cliente estamos interfiriendo en el proceso de escuchar. 4. La preocupacin: Todos somos humanos. Habr momentos en que estemos preocupados por problemas
personales o por negocios. Es importante permanecer alerta durante la venta y no dejar que esto interfiera con nuestro propsito. Cuando entremos y crucemos la puerta del cliente, debemos dejar todas esas distracciones atrs.
5. El mal uso de las palabras: Este es un problema de doble consecuencia. En primer lugar, el cliente
puede tener dificultad para expresarse y dar a entender cosas que no pretende decir. Esto nos puede confundir o nos puede llevar a interpretar mal el mensaje. En segundo lugar, podemos ser culpables de utilizar mal las palabras e interpretar mal lo que un cliente nos diga. En el primer caso, es importante hacer preguntas si sospechamos que el cliente no se expresa con claridad. En el segundo caso, tenemos que concentrarnos en mejorar nuestra propia capacidad de expresin y nuestro vocabulario.
COMO MEJORAR LOS HABITOS DE ESCUCHAR CON ATENCION

Hay mltiples tcnicas exitosas que podemos utilizar para mejorar nuestros hbitos de escuchar. Todas son tcnicas sencillas y todas requieren autodisciplina.
Pg. 142 de 200
1. No interrumpir: Nada anula tanto la comunicacin como la interrupcin. Al interrumpir la lnea de ideas
del cliente, interrumpimos tambin nuestro proceso de escuchar. La interrupcin constante da como resultado un cliente que no est dispuesto a hablar. Adems, lo ms seguro es que el cliente se sienta molesto con nosotros.
2. Aprender a escuchar entre lneas: Por lo general hay una discrepancia entre lo que el cliente dice
y lo que realmente quiere decir. Es posible que el cliente est tratando de ocultar un problema en sus operaciones, o que no est seguro de cul es el verdadero problema. En cualquier caso, la nica forma de determinar el verdadero significado de lo que el cliente est diciendo es escuchar con atencin. Escuchamos entre lneas cuando observamos tanto la comunicacin no verbal del cliente como la que vemos a nuestro alrededor.
3. Concentrarse en desarrollar la capacidad de retencin: El tomar demasiadas notas se puede convertir en una "muleta" si confiamos demasiado en ello. Interfiere con nuestra capacidad mental de retener informacin. Sin embargo, cuando un cliente nos presenta toda una lista de cifras de produccin, es posible que nos veamos obligados a tomar notas. En este caso resulta til. Le indica al cliente que somos personas serias y que nos preocupamos. 4."No desintonizar al cliente": Todos nos hemos encontrado con clientes aburridores o con clientes que no cesan de hablar de temas sin importancia. Es probable que muchas veces hayamos "desintonizado" a estas personas por pensar que no vamos a obtener nada valioso de su conversacin. En esto hay dos desventajas: primero, estamos desarrollando hbitos de escuchar con pereza que pueden interferir con informacin valiosa y segundo, estamos perdiendo informacin til. Vimos tambin en la pelcula que el cliente se puede sentir molesto cuando se da cuenta de que estamos fingiendo inters. Si una conversacin se prolonga indefinidamente, podemos, con mucho tacto, llevar al cliente de nuevo al tema que nos interesa con una pregunta gua. 5. No adoptar una actitud hostil ni emocional mientras escucha: Podemos ahogar cualquier sonido si dejamos que domine la ira mientras escuchamos a alguien con quien no estamos de acuerdo. En primer lugar, es posible que el cliente no sepa que disentimos: en segundo lugar, si no estamos de acuerdo, habr tiempo de sobra durante nuestra presentacin de ventas para expresar nuestro punto de vista. Si estamos en desacuerdo con relacin a algo que no tiene que ver con nuestro negocio, es mejor dejar nuestros sentimientos tcitos. 6. Aprender a ignorar las distracciones: No vale la pena de dejarnos distraer por influencias
ajenas durante la presentacin de ventas. Si estamos bien disciplinados en nuestros hbitos de escuchar, ser ms fcil anular las distracciones. Es til recordar que, aunque el ambiente del negocio nos puede distraer, es probable que est acostumbrado y que a l no le afecte tanto como a nosotros. Es importante reconocer que el saber escuchar es un proceso que requiere autodisciplina. Todas las sugerencias hasta ahora explicadas estn orientadas a fomentar la auto disciplina y se pueden aplicar a nuestras experiencias diarias.
EL CIERRE DE LA VENTA
La capacitacin prctica en el campo de las ventas ha progresado considerablemente durante los ltimos veinte aos. No obstante, resulta sorprendente que el cierre de la venta no haya perdido su carcter misterioso y enigmtico, como si no tuviera relacin alguna con el resto del proceso de la venta. Por lo dems, con frecuencia encontramos vendedores muy capaces que se desmoronan ante la necesidad de cerrar una venta. MANUAL TCNICO PMI - IT El CIERRE DE LA VENTA retira el velo de misterio que rodea este paso final al considerarlo como la culminacin de los diferentes pasos que han llevado a un vendedor hasta ese momento. Por medio de una serie de escenas que describen situaciones comunes en donde se cierran diferentes ventas, y mediante la colaboracin de tres importantes consultores en ventas y mercadotecnia, la pelcula demuestra con claridad que el cierre de la venta es el resultado lgico del empleo de destrezas adecuadas de ventas. Los consultores tambin presentan varias tcnicas que ayudan al vendedor a cerrar sus ventas cuando debe tratar con clientes especialmente difciles.
Pg. 143 de 200
Qu deben hacer los vendedores cuando presienten que es propicio el momento para tomar el pedido? LA TECNICA DE SUPONER EL CIERRE
Se sugiere un sistema que podra ensayar un vendedor, a saber, suponer el cierre. Esta tcnica implica que el vendedor d por hecho que el comprador est dispuesto a comprar, y es una manera til de verificar hasta qu punto se siente comprometido el cliente. Para que este sistema produzca los resultados esperados, el vendedor debe ser asertivo. El vendedor se arma de valor y solicita el pedido. El comprador reflexiona y, para sorpresa de ambos, anuncia que est cerrado el trato. El cierre consta de una serie de hechos y no de un hecho aislado ".
LA TECNICA DE CIERRE SI... ENTONCES...

Un ejemplo nos muestra un vivero poco antes de ser inaugurado. Un vendedor de sistemas de riego, presenta su producto a Joan y a Karen, quienes aparentemente son las encargadas de las compras en el nuevo vivero. Mike la felicita por la excelente distribucin de las instalaciones. Joan responde que ella y Karen son las dueas y que lo hicieron todo. Lo que parece ser una conversacin superficial a menudo puede proporcionar la clave para el cierre de la venta. Gentry seala que Mike ha utilizado la tcnica conocida como clasificacin o evaluacin del cliente. Por medio de preguntas. Mike se enter de que Joan y Karen tienen autonoma para decidir, ya que sern quienes decidirn si compran o no. Mike sigue avanzando hacia el cierre de la venta, formulando preguntas a fin de conocer los problemas de sus clientes y suministrar la solucin adecuada. Les pregunta a las dueas del negocio si sera posible que l describiera sus necesidades con sus propias palabras. Con esta tcnica Mike nos hace saber que el cierre de la venta consiste en realidad en una serie de hechos: en este caso, en una serie de acuerdos entre el vendedor y su cliente. Cada vez que Joan y Karen dicen "s", Mike se acerca ms al cierre. Joan y Karen le informan que lo que ms les preocupa es el costo inicial de la instalacin del sistema de riego que Mike considera ideal para su vivero. La mayor parte de su capital est invertido en las existencias, y temen exceder su capacidad. Las dueas del negocio han comenzado a dudar acerca de la posibilidad de comprar el sistema de riego que les ofrece Mike. Se discute la encrucijada en la que se encuentra Mike. Llegan a la conclusin de que en este caso no es adecuada la tcnica de "Quieren ustedes comprar" ya que es obvio que Joan y Karen s desean comprar. La dificultad parece ser el costo inicial del sistema de riego. Cole sugiere la tcnica de Si...entonces, la cual adiciona un ingrediente. Gentry se muestra de acuerdo y agrega: "Si la necesidad es real, la tcnica Si...entonces la adecuada". Mike procede a utilizar esta tcnica con Joan y Karen por medio de incentivos para aumentar su deseo de contar con el sistema de riego. Uno de estos incentivos consiste en decirles que si el pago se divide en varias cuotas, entonces costo inicial se podra pagar con mayor facilidad. Joan y Karen se muestran indecisas, pero ya que Mike insiste en su tcnica, finalmente acceden. Mike les ha ofrecido una alternativa factible que no representar una carga financiera demasiado considerable para su nuevo negocio. Los consultores se muestran satisfechos con el xito de la tcnica Si...entonces" en esta situacin. George Caras les pregunta a los otros consultores si esta tcnica es la mejor que se puede emplear con un cliente que presenta objeciones. D'Aulan Gentry sugiere que puede ser efectiva cuando el vendedor se enfrenta a un cliente levemente Pg. 144 de 200 MANUAL TCNICO PMI - IT
indeciso. Sin embargo, los consultores aceptan que quiz se requiera de una tcnica ms drstica cuando la indecisin de los clientes sea extrema.
LA TECNICA DEL HECHO INMINENTE

El escenario es ahora una sala de juntas de una importante corporacin. Tom, vendedor de sistemas para el procesamiento de datos, resume su presentacin a tres ejecutivos, Carole, Pete y Harold. Se puede apreciar que Carole est a favor de comprar el sistema que vende Tom. Pete es el ms indeciso y parece inquietarle la perspectiva de tener que tomar una decisin. A Harold le tiene sin cuidado la decisin, y seguramente votar con la mayora. Cuando Carole trata de persuadir a Pete para que d su aprobacin y a Harold para que participe, la reunin se torna bastante conflictiva. Pete se siente an menos dispuesto a asumir la responsabilidad Harold cambia el tema y, en el fondo de la sala, Tom ve esfumarse todas sus posibilidades. Los consultores comprenden perfectamente la posicin de Tom. Caras seala que Tom perdi todo el control de la situacin. En ocasiones el vendedor debe actuar como catalizador para que la venta se convierta en realidad. Un vendedor que ha hecho una buena presentacin al evaluar al cliente, comprender sus necesidades y satisfacerlas, tiene todo el derecho para actuar enfticamente para lograr la venta. Cole sugiere que Tom debe ensayar una de esas tcnicas positivas y enfticas, la del Hecho Inminente. De regreso en la sala de juntas vemos que la discusin ha subido de tono. Sbitamente, Tom interrumpe y con mucha firmeza exige que los ejecutivos tomen una decisin...ahora mismo. Afirma que es necesario que lleguen a un acuerdo con prontitud por su propio bien si desean que el sistema est en funcionamiento para cuando llegue le perodo de mayor actividad comercial para la corporacin. Los ejecutivos no saben qu responder. Tom pide permiso para retirarse de la reunin y as dejarlos en libertad de tomar una decisin en privado. Transcurridos unos pocos minutos, Carole sale de la sala de juntas. Le informa a Tom que el negocio es un hecho. En este caso, el uso oportuno de la tcnica del Hecho Inminente oblig a unos ejecutivos indecisos a enfrentar la necesidad de tomar una decisin. Esto no es vender por la fuerza; por el contrario, es una forma de lograr que el cliente se concentre nuevamente en el propsito de la presentacin del producto. Tom logr con xito la venta al tomar las riendas en una situacin que exiga control. Se procede a analizar si el cierre de la venta es en s una culminacin. Caras reitera que el cierre es solamente un momento dentro del proceso, y, lo que es ms importante, es el inicio de una relacin comercial y el primer paso hacia el siguiente pedido. A manera de ejemplo, regresamos a los talleres de impresin en donde comenz la pelcula. Frank y el seor Shelley estudian la posibilidad de introducir mejoras a la unidad de impresin que Frank logr vender al comienzo de la pelcula. Es obvio que el seor Shelley est escuchando y que esta relacin entre vendedor y cliente ha progresado considerablemente. En el vivero, Mike est instalando una unidad adicional de riego que las compradoras pudieron adquirir en un principio. Cole comenta: "El cierre de la venta es un proceso. Crece y se renueva, generando nuevos negocios". Las habilidades adecuadas son la mejor respuesta para eliminar los temores de un vendedor. La prctica de estas habilidades garantiza el xito.
Las habilidades que debe desarrollar y emplear un vendedor, y que hemos visto en EL CIERRE DE LA VENTA son: 1. 2. 3. 4. Evaluacin del cliente Conocimiento de las necesidades del cliente a travs del sondeo Vender el beneficio de satisfacer dichas necesidades y Detectar el momento propicio al poco tiempo de haber iniciado el proceso de venta. Pg. 145 de 200
ELEMENTOS A CONSIDERAR ANTES DE PROCEDER AL CIERRE
Se enumeran las tcnicas que dieron lugar al xito en las ventas: 1. 2. 3. La tcnica de Suponer el cierre, La tcnica del Si...entonces y La tcnica del Hecho Inminente.
Por ltimo, el consejo final de estos tres expertos NUNCA TENGA MIEDO DE SOLICITAR EL PEDIDO!
COMO VENDER A CLIENTES DIFICILES

Una de las habilidades ms importantes en el campo de las ventas consiste en evaluar a los clientes y responder a sus personalidades de tal manera que se obtenga una buena venta. Sin embargo, frente a un cliente difcil, el vendedor no sabe que hacer para entender las motivaciones del cliente y, en general, no est preparado para remediar la situacin. COMO VENDER A CLIENTES DIFICILES examina en forma agradable el problema, hace hincapi en las ventas al detalle y en las de mercados industriales. Esta pelcula presenta algunas tcnicas para tratar con clientes difciles y da detalles sobre la psicologa que los motiva, tanto a ellos como a los vendedores. Se da importancia especial a los cuatro tipos de personalidades "problema". En esta parte presentamos a cuatro clases especiales de personas con quienes se va a encontrar el vendedor comn en el mercado al por menor o industrial: el quejumbroso, el sabiondo, el indeciso y el indiferente. Aunque esta "cuadrilla de cuatro" representa una amplia rea de conducta, la personalidad humana es demasiado compleja para entender sin un anlisis ms detallado de los rasgos de conducta o las razones que la enmarcan. Al encontrar estos tipos de conducta, el vendedor debe aprender la respuesta apropiada que le permita actuar con eficiencia y, adems debe recordar que la mayora de los clientes representan tipos de personalidad combinados. Esta gua presenta un anlisis dirigido especialmente a las tcnicas de venta pertinentes.
CONOZCA AL CLIENTE
COMO VENDER A CLIENTES DIFICILES establece que "...para efectuar una venta hay que penetrar en la mente del cliente para conocerlo y saber lo que quiere". El vendedor eficiente debe adquirir la habilidad de analizar y adaptarse a los tipos de clientes y a las necesidades personales y emocionales que puede ver reflejadas en ellos. Vender, es, esencialmente, un acto de teatro que el vendedor controla la venta como un actor, respondiendo a las pistas que recibe del cliente. Adems, como no hay un guin, el vendedor ha de tener la cualidad de la percepcin. Nosotros como seres complejos: nuestras motivaciones y percepciones no siempre se definen claramente: pero, cuando una persona sabe lo suficiente sobre la conducta humana para entender dichas bases, se puede predecir la manera en que la gente va a actuar frente al vendedor. Todas las personas poseen cualidades diferentes que pueden, en diversas ocasiones, dominar su personalidad y sus acciones. En su libro, Ventas: Un anlisis conductista y gerencial. Joseph Thompson elabor una lista de las diez caractersticas que predominan en la mayora de los clientes. 1. El cliente silencioso 2. El lento 3. El manipulador 4. El metdico 5. El desconfiado 6. El obstinado Cristian Bailey Consultor IT Pg. 146 de 200 MANUAL TCNICO PMI - IT
7. El escptico 8. El pesimista 9. El impulsivo 10.El discutidor Antes de entrar en un anlisis ms detallado, hay que reconocer cuatro peligros que es preciso evitar en el proceso de anlisis de clientes. El vendedor no debe pretender ser un psiclogo aficionado. Por el contrario, actuar como observador de personalidades pensando las caractersticas del cliente, analizando y empleando la tcnica correcta. El propsito de este anlisis no es descubrir las fallas en la personalidad del cliente o las razones psicolgicas profundas que expliquen su conducta. El vendedor tampoco debe tratar de clasificar al cliente demasiado rpido; las primeras impresiones no siempre son objetivas.
Hay que recordar la historia de aquel vendedor de automviles que no prest atencin a un cliente joven, sin afeitar, con camiseta, sandalias y pantaln corto y prefiri dedicarse al caballero elegante que lleg con una dama atractiva del brazo: "Despus de todo", pens el vendedor "yo vendo automviles caros". Result que el caballero slo estaba mirando en tanto que la persona desarreglada, un msico famoso llevaba 15,000 dlares en efectivo para comprar inmediatamente un auto y se lo compr al distribuidor de enfrente. Si el vendedor hubiera dedicado unos minutos de su tiempo para confirmar la intencin, no habra perdido la venta. Finalmente, el vendedor no puede esperar que el cliente se comporte siempre de la misma manera: la gente, simplemente, no es congruente. Un cliente que puede ser agresivo la primera vez, tal vez se demuestre entusiasta y amable en la segunda oportunidad: el cliente tambin puede cambiar de personalidad en el curso de la venta: el vendedor debe ser paciente y permanecer atento mientras logra la clasificacin de la personalidad del cliente. El consejo ms importante que se le puede dar al vendedor frente a un cliente nuevo es que sea flexible y est preparado para tratarlo segn su manera de actuar en el momento y adaptarse a esa conducta a la vez que cataloga y hace un anlisis definitivo de la personalidad del cliente en una fecha posterior. Mientras el vendedor realiza el anlisis, no debe ignorar la imagen que el cliente tiene de s mismo, o sea su ego ideal. Esta auto imagen aunque no corresponde a la realidad, puede ofrecer pistas valiosas en la definicin de su carcter. Por ejemplo, un vendedor puede percibir la indecisin de un cliente sin acudir a la opinin de otros, mientras que el cliente puede creer que dicha consulta es un medio para lograr el desarrollo de sus subordinados. Sea o no cierto esto, el conocimiento del ego ideal del cliente ayuda al vendedor a manejarlo con xito.
CLASES DE CLIENTES Y COMO TRATARLOS

El vendedor debe recordar que por muy completa que sea esta lista de tipos de personalidad, ningn individuo va a externar una de ellas solamente. Cada uno posee varias caractersticas de la misma manera que podemos identificarlas en nosotros mismos. Para detectar algunas de las causas de estas conductas lo mismo que las tcnicas bsicas para vencerlas, el vendedor deber superar dichas barreras de personalidad para comenzar a vender.
1. EL CLIENTE SILENCIOSO: se muestra aqu como el INDIFERENTE. Es difcil lograr que se interese. Al vendedor le resultar difcil la charla sobre la situacin especfica de la venta.
Pg. 147 de 200
Puede ser que el cliente permanezca callado por varias razones: es posible que se le dificulte hablar, que le falte seguridad en s mismo o que sea del tipo distante o analtico. Si el representante de ventas se enfrenta a un cliente como ste sin tener preparacin previa, no va a identificar las razones de sus silencio. Hay varias tcnicas capaces de lograr entusiasmar al cliente silencioso. Puede pedrsele su opinin o que explique ciertos puntos. Adems, puede ensayarse un acercamiento ms personal: por ejemplo, hablar de temas inapropiados para el objetivo inmediato del vendedor, pero que ayudan a romper el hielo. En general, se requiere mucha paciencia por parte del vendedor para tratar a un cliente como ste.
2. EL CLIENTE LENTO: pertenece a la personalidad del INDECISO. La gente difiere la toma de decisiones porque stas se le dificultan. Ms que por indecisin, posponen las cosas porque no pueden aceptar cambios fcilmente. Los lentos son muy precavidos e insistirn en examinar todas las opciones antes de tomar una decisin aunque, de todas maneras, se les dificulte decidir.
Para tratar a una persona como sta, el vendedor debe ser optimista, seguro de s mismo y persuasivo: debe alabar al cliente y sus habilidades en su rea de trabajo. A veces da buenos resultados poner de relieve las prdidas que ocasiona la demora en la decisin, aunque se debe evitar que el cliente se sienta insultado. En resumen, el vendedor debe ganarse la confianza del lento antes de tratar de lograr una buena venta.
3. EL CLIENTE MANIPULADOR: que comparte caractersticas de personalidad con el SABIONDO,

puede ser un individuo enloquecido que va a tratar de invertir las funciones y de venderle al vendedor. En algunos caso, el representante de ventas puede visitar a un cliente como ste por aos sin lograr un negocio completo. Los dos se aprecian, se elogian sus empresas y productos, pero el manipulador siempre desviar el tema y hablar de cosas diferentes, lo que no conducir a una venta. La frase "A propsito, esto me recuerda que..."puede ser muy til. El vendedor debe mantener el curso de las ventas, ser breve y, en lugar de entusiasmarse junto con el cliente, debe darle material sobre las ventas. El mejor consejo en este caso es el viejo axioma de ventas: "Sea eficiente, sea breve y vyase". De otra manera, se perder mucho tiempo.
4. EL CLIENTE METODICO: est especialmente caracterizado por ser el SABIONDO de la pelcula. Con
frecuencia, el vendedor tiende a no prestarle atencin suficiente, creyendo que su reaccin lenta indica falta de inters o de inteligencia. En realidad, el cliente puede ser metdico porque necesita autonoma o control, orden y un pensamiento lgico o porque le es importante preguntarse, mirar, escuchar, inspeccionar. El vendedor tiene que disminuir su ritmo y el vendedor ha de practicar el arte de escuchar.
5. EL CLIENTE DESCONFIADO: no es del tipo de personalidad asertiva; se parece ms al INDECISO

de la pelcula. Este cliente parece inseguro y busca siempre el consejo y las recomendaciones de los dems antes de tomar una decisin. El vendedor observa cmo el cliente, en ocasiones, consulta a sus colegas que pueden ser expertos en ciertas reas, mientras que en otro caso lo hace para evitar asumir la responsabilidad. El cliente tal vez tenga una fuerte necesidad de asociarse debido a una falta de seguridad en s mismo. Tambin puede ser dependiente por miedo al fracaso que paraliza la capacidad de actuar. El vendedor tiene que darle seguridad al cliente mostrndole que lo comprende, con explicaciones sencillas y con sinceridad. Despus de crear una relacin de confianza, puede darla ms seguridad usando hechos concretos, como los resultados de pruebas, materiales y testimonios. MANUAL TCNICO PMI - IT
6. EL CLIENTE OBSTINADO: tiene caractersticas comunes con el SABIONDO de la pelcula. Cree que
conocer todas las respuestas, toda la informacin sobre la compaa del vendedor y el producto ( an antes de la presentacin ) y pretende controlar la entrevista. Cree que slo sus juicios, opiniones y predicciones son correctos... y considera negativos cualquier sugerencia o consejo del vendedor. Toda persona tiene la necesidad de lograr algo: de vencer obstculos, de ejercer algn dominio y de ser reconocido por lo que ha hecho. Algunas veces esta necesidad se puede manifestar en el individuo con una actitud en beneficio propio por una tendencia a esperar alabanza y respeto o a buscar distinciones; es decir de atraer Pg. 148 de 200
atencin sobre s mismo. Por lo tanto, se entiende que esta persona tenga una necesidad tan fuerte de dominar una venta. En estos casos, el objetivo bsico del vendedor es hacer que el cliente se sienta importante. Sus ideas no pueden parecer definitivas y ms bien debe pedir opinin y consejo al cliente. En consecuencia se le permite controlar la entrevista ya que presenta hechos con un propsito bien definido. Es necesario mostrar una actitud tolerante porque el conflicto de personalidades, puede resultar contraproducente y costoso.
7. EL CLIENTE ESCEPTICO: tiene cualidades comunes con las del SABIONDO. Parece tener respuestas
negativas para todo y mostrar desconfianza ante el vendedor: reacciona de una manera similar a el OBSTINADO en la necesidad de dominar. Pero, en lugar de mostrar que conoce todas las respuestas, se limita a rechazar la informacin que le presentan y da muestra de un temperamento negativo. El vendedor debe actuar con cuidado y hacer afirmaciones que no vayan contra s mismo. Si deja que el escptico lo atrape en sus exageraciones, perder credibilidad. Si hace hincapi en los hechos y acta de manera lgica y abierta sobre el producto ( ya que ningn producto es perfecto) podr manejar mejor al cliente, mantener su credibilidad y controlar la entrevista.
8. EL CLIENTE PESIMISTA: tiene algunas de las caractersticas del QUEJUMBROSO de la pelcula.

Despus de haber formulado el saludo rutinario, muchos vendedores reciben con asombro un torrente de conversacin impertinente por parte del cliente. Este puede estar descontento con el producto o con la situacin mundial; pero no importa el tema que sea, el caudal de informacin ser su respuesta pesimista a la tensin y su manera de desahogarse. Si plantea preguntas con tacto, el vendedor se sorprender al descubrir las razones ocultas detrs de la situacin del pesimista, que pueden no tener nada que ver con lo que se ha estado diciendo. Es responsabilidad del vendedor asumir el papel optimista permaneciendo tranquilo, actuando contacto y ofrecindole consuelo e ideas constructivas. Procure no dejarse absorber por el pesimismo del cliente porque esto originara una entrevista ineficiente que podra desembocar en una situacin deteriorada.
9. EL CLIENTE IMPULSIVO: tiene cualidades que tambin se encuentran en el QUEJUMBROSO de la

pelcula. Generalmente habla rpido, con brusquedad y muestra cambios igualmente repentinos. Como necesita dominar y acumular logros, acta de modo imprevisible, lo cual contribuye a mantener un descontrol en los dems. Aunque es difcil saber con certeza por qu lo hace, parece que por el orgullo en su manera de actuar. EL CLIENTE IMPULSIVO tiene cualidades que tambin se encuentran en el QUEJUMBROSO de la pelcula. Generalmente, habla rpido, con brusquedad y muestra cambios igualmente repentinos. Como necesita dominar y acumular logros, acta de modo imprevisible, lo cual contribuye a mantener un descontrol en los dems. Aunque es difcil saber con certeza por qu lo hace, parece ser que por el orgullo en su manera de actuar. El representante de ventas debe considerar su relacin con el IMPULSIVO como un acto de equilibrio: hay que responder con rapidez, adaptarse a su ritmo y omitir detalles segn el caso. Pero aunque los detalles se omitan, se presentan hechos suficientes para que el cliente sepa en qu se basa la decisin; de otra manera, puede cambiar repentinamente y la venta se habr perdido innecesariamente.
10. EL CLIENTE DISCUTIDOR: tiene rasgos comunes con el QUEJUMBROSO. Este cliente querr
iniciar una discusin: contra la compaa y el producto. Adems, se pondr en favor de la discusin como una persona inferior y de la que se puede abusar. A pesar de su apariencia de superioridad, este cliente generalmente es inseguro y por eso necesita degradar a los dems y comportarse contraria- mente a su personalidad. El vendedor no debe discutir pues no ganar nada. El valor y la sinceridad son las que producirn respeto en una situacin como sta, an en las circunstancias ms difciles. Cristian Bailey Consultor IT Pg. 149 de 200
DETECTANDO LAS NECESIDADES DEL CLIENTE

PROPOSITO
En toda situacin de venta, el vendedor afronta el problema de averiguar las necesidades del cliente, antes de comenzar a presentar un producto o servicio. Por muy eficaz que sea la presentacin, el vendedor perder su tiempo si no mantiene una actitud bastante abierta para permitirle obtener informacin del cliente y la clave para realizar la venta. En este curso se examina el problema de detectar necesidades de los clientes y se ofrecen una serie sistemtica de preguntas, que pueden emplearse para suministrar al vendedor informacin con que podr adaptar la presentacin a las necesidades del cliente y conseguir una buena venta.
1. Preguntas generales: planteadas en trminos generales para que el interlocutor tenga

plena libertad de contestar como desea.
2. Preguntas especficas: su finalidad es reducir un tema a informacin bsica y concreta. 3. Preguntas de sondeo: cuya finalidad es centrar la atencin a los problemas reales, o
sea los verdaderamente importantes.
4. Preguntas que sugieren la respuesta: su finalidad es ayudar al cliente cuando parece

incapaz de definir sus necesidades personales.
INFORMACION BASICA
En el pasado, cuando se pensaba que la venta era ante todo el arte de convencer por medias espectaculares, el vendedor llegaba a la oficina del cliente y, gracias a su arrolladora personalidad y don de palabra, ofreca una presentacin muy agradable, cuyo fin era ganarse la admiracin de todos los asistentes. Desde el punto de vista de los clientes, todo esto resultaba a veces muy cansado pues muchas de las promociones de venta correspondan a las necesidades de su empresa. En los ltimos aos, los expertos han tratado de organizar de una manera ms lgica el arte de la venta; se ha desarrollado as el concepto de la determinacin rigurosa y sistemtica de los factores relacionados con la venta. A este primer paso suele designrsele con el nombre de "precontacto": consiste en realizar investigaciones y en hacer los preparativos pertinentes antes que se encuentre el vendedor con el cliente. La mayor parte de los vendedores no realizan un buen precontacto y el resultado de ello puede ser un presentacin de ventas a alguien que no necesita el producto o que carece de autoridad para adquirirlo. En la presente seccin se examinan tcnicas que las autoridades en la materia recomiendan utilizar, para que el vendedor est mejor preparado y tenga mayor seguridad cuando entre en la oficina de un cliente. MANUAL TCNICO PMI - IT
PRECONTACTO
Antes de reunirse con un cliente, el vendedor ha de prepararse para la visita. En este perodo, llamado "precontacto, se efecta la investigacin con que se determinan varios aspectos bsicos que aumentan las probabilidades de realizar la venta. Es importante recordar que la comunicacin con el cliente ser mejor si se funda en informacin reunida antes de la entrevista incluye desde la ms bsica (por ejemplo, el nombre completo del cliente) hasta la ms importante (la Cristian Bailey Consultor IT Pg. 150 de 200
autoridad o la capacidad de pagar, por ejemplo). Desde luego, tal vez no sea posible conocer todos los detalles antes de la reunin con el cliente, pero cuanto ms se investigue mejor para todos. Archivos de la compaa. A menudo, con slo consultar los archivos de su empresa, el vendedor consigue las respuestas a las preguntas referentes a los clientes y a las transacciones. As, esos documentos suelen proporcionar informacin sobre quines estn autorizados para realizar compras en una compaa, si bien esos datos no siempre estn actualizados. Los archivos internos casi siempre suministran informacin confiable sobre el crdito de un cliente y (si el vendedor desea informacin sobre un cliente al que ya se le ha vendido antes) anteriores hbitos de compra. Toda informacin que se recabe con este mtodo ser til cuando se visite al cliente y seguramente ahorra tiempo para localizarlo. Observacin e investigacin personal. Con una visita a la sede de la empresa del cliente, un vendedor observador consigue mucha importante informacin. La Scott Paper Company recomienda la fuerza de ventas: Preparar de antemano una presentacin que garantice cierta habilidad dar al vendedor la apariencia de haber hecho arreglos destinados exclusivamente al cliente. Y adems esa tctica le permite conocer bien las necesidades e ideas del cliente. Por ejemplo, si va averiguar que a ste le interesa sobre todo el costo bajo, cometera un error si insistiera en las caractersticas de calidad del producto debido a su presentacin. La ventaja principal de la investigacin es que el vendedor est preparado. Tendr, pues, mayor seguridad y se reducir el nmero de factores desconocidos que le aguardan en la oficina del cliente y la seguridad en s mismo es una cualidad indispensable del vendedor eficiente. En su libro Ventas, Frederic Rusell recomienda una serie de preguntas que el vendedor debera contestar antes de reunirse con el cliente. Las preguntas caen en tres categoras: personal de la compaa, operaciones de la compaa y procedimiento de compra de la compaa.
Personal de la compaa
1. Quin es el dueo de la compaa? 2. Si se trata de una corporacin, quienes forman parte del consejo de administracin? 3. Cules son las lneas de negocios de esos ejecutivos? 4. Conozco a alguno de ellos? 5. Quin toma la decisin definitiva en materia de adquisicin? 6. Qu otra persona tiene influencia en las compras? (a veces el vendedor prefiere acudir al nivel de alta direccin; otras veces obtiene el apoyo de los subordinados.) 7. Quin es el jefe del departamento que utilizar mi producto o servicios?
Operaciones de la Compaa
MANUAL TCNICO PMI - IT Pg. 151 de 200 1. Qu produce o vende? 2. A qu mercado llega? 3. Es el producto de alta calidad, de calidad mediana o baja? 4. Existen factores estacionales?
5. Qu lugar ocupan en su industria? 6. De qu tipo y estructura es su equipo?
Procedimiento de compra de la Compaa

1. Qu sistemas y procedimiento sigue su departamento de compras? 2. Compra la compaa a unos cuantos proveedores o se diversifica en sus adquisiciones? 3. Cul es su clasificacin de crdito? 4. Cundo compra mi producto? 5. Cunto compra en cada transaccin? 6. A quin le compra ahora y por qu? 7. Est la compaa satisfecha con su proveedor actual? 8. Qu problemas ha tenido con su proveedor actual? 9. Se beneficiar si compra y usa lo que yo vendo? Si un vendedor puede contestar la mayor parte de estas preguntas antes de visitar a un cliente, aumentar de manera notable su seguridad.
EL CONTACTO
Un vendedor entra en la sede del negocio de un cliente. Sin importar si se trata de una oficina, una tienda o una residencia, hay mucho que ver y aprender desde el momento en que atraviesa el umbral; todo ello le servir para enterarse de las necesidades y situacin del cliente. En una oficina, puede obtenerse mucha informacin con slo observar lo que piensan del cliente los otros empleados. Por ejemplo, observar lo que piensan del cliente los otros empleados. Por ejemplo, un cliente puede tener la reputacin de ser una persona muy desagradable y descorts; pero si sus subordinados no externan seales de sentirse intimidados por l, quiz se trate simplemente de una tctica para mantener alejados a los vendedores y no refleje la verdadera personalidad del cliente. En una tienda el vendedor deber ser capaz de adaptar bien su estrategia de ventas si observa con atencin las existencias, el comportamiento de los dependientes y si capta con claridad las actitudes del cliente ante las compras. En la sede del negocio del cliente, sin importar su ubicacin, se vern indicaciones de un pasatiempo de inters especial: quiz un trofeo de pesca o un diploma por actividades de caridad. Un inters comn en algn pasatiempo o actividad pueden servir para iniciar una conversacin o establecer una relacin con el cliente, pero no olvide que todo vendedor que entra en esta oficina estar buscando las mismas pistas, y el cliente perder inters si se habla mucho del pasatiempo. He aqu una regla que ha de observarse: cuando est en su negocio, el cliente prefiere hablar de negocios. Ya se ha roto el hielo. El vendedor ha logrado crear una relacin personal. Ahora es tiempo de aplicar una tcnica sistemtica de interrogatorio para averiguar las necesidades del cliente y su situacin actual.
Pg. 152 de 200
El arte de interrogar
Un aspecto fundamental que es preciso tener en cuenta al estudiar tcnicas del interrogatorio es que las preguntas no darn resultado si no se acompaan de buenos hbitos de escuchar con atencin. Las preguntas aportan informacin directa, pero la escucha activa producir en forma discreta la misma cantidad de informacin. En su entusiasmo inicial, el vendedor puede dejarse llevar por su presentacin, sin dar tiempo a que el cliente tome la palabra durante la entrevista. Es preciso que se controle, recordando que a la gente le gusta hablar e inconscientemente revela su personalidad durante la conversacin. Una informacin de este tipo aporta mucho ms que un monlogo y si el vendedor escucha con atencin obtendr la clave para realizar la venta. Si logra que el cliente hable con entera libertad, el vendedor lograr determinar los aspectos bsicos de las necesidades y deseos de aquellos. El vendedor deber utilizar preguntas que lleven al cliente a reas generales de informacin que le interesan. Es preciso saber transmitir el inters y estimular el flujo libre de la conversacin. En la pelcula se vio que hay cuatro tipos de preguntas con las cuales pueden averiguarse las necesidades del cliente: 1. Preguntas generales 2. Preguntas especficas 3. Preguntas de sondeo 4. Preguntas que sugieren la respuesta
Preguntas generales Segn se afirm en la pelcula, el propsito de una pregunta general es ayudarnos a determinar los objetivos corporativos globales de los empleadores del cliente. Una pregunta general podra expresarse en los siguientes trminos: Cmo marchan las cosas en su nueva fbrica?
Al iniciar la entrevista con una pregunta general y no con una especfica, el vendedor puede estimular al cliente para que en su conversacin ofrezca informacin til. (Una pregunta especfica planteada al inicio puede hacer que el cliente piense que el interlocutor le pedir siempre la informacin que necesita, y ello impulsar a no dar informacin que podra ser til para el vendedor) En esta etapa temprana, un vendedor deber hacer preguntas que requieren una explicacin como respuesta. Entre otras tcnicas tiles figura la de pedir al cliente que explique las cosa con detalle, parafraseando lo dicho por el cliente o guardando silencio, lo que puede alentar al cliente para proseguir. Parafrasear es til, porque repetir con sus propias palabras lo que dijo el cliente, el vendedor podr aclarar las generalizaciones y descubrir lo que realmente piensa el otro. Preguntas especficas. Estas preguntas pueden ayudar al vendedor a averiguar cmo se usa su producto o servicio. Algunas veces seran preguntas de "quin, qu cosa, dnde, cundo, cmo y por qu"; se trata, pues, de preguntas detalladas como la siguiente: Cul es su volumen diario en este mes? Las respuestas revelarn hechos que nos pueden ayudar a adaptar mejor el mtodo a las necesidades del cliente. Una vez ms insistimos en que estamos todava en la fase de obtencin de la informacin y un vendedor debera analizar esta informacin y compararla con su investigacin efectuada antes del precontacto. Preguntas de sondeo. Con ellas se investigan las cuestiones fundamentales en cualquier relacin con el cliente; ese conocimiento permitir al vendedor adoptar un ngulo o punto de vista en el cual basar su presentacin. Dichas preguntas abarcan una amplia variedad de problemas o deseos, con el propsito de hacerse una idea clara de la cuestin central, sin importar si el cliente lo reconoce o no. Recurdese que a menudo el cliente no se percata de Pg. 153 de 200 MANUAL TCNICO PMI - IT
cul es su verdadero problema; a veces incluso ni sabe que existe un problema. Hay varias maneras de formular preguntas de sondeo. Le gustara... como en esta pregunta: Le gustara tener un producto como el nuestro? Un cliente entra en un lote de exhibicin de automviles y da varias vueltas a cierto modelo. Si el representante inicia la entrevista con las palabras". Le gustara un modelo como ste? El cliente contestar afirmativamente o le dir cul le parece mejor. En una u otra forma, el vendedor podr determinar las necesidades del cliente con una sola pregunta y dar un paso importante en la realizacin de la venta. Adems, habr descubierto muy pronto si hay algo que se puede hacer por l, con lo cual ahorrar tiempo muy til y posiblemente se gane el respeto y el aprecio del cliente. "S..." como en Si yo pudiera incrementarle sus utilidades en 10%, le interesara mi oferta? Supngase que un cliente pide una tela que ya no se fabrica. Al contestar Si pudiera conseguir un material parecido? Le interesara adquirirlo? El vendedor logra varias cosas. En primer lugar, reconoce de inmediato que no podr venderle al cliente lo que l quera; sin embargo, lo ha invitado a ajustar sus exigencias a lo que est disponible, algo que la mayor parte de los compradores estn dispuestos a hacer. Y es posible que haya salvado una venta en una situacin donde un simple "Lo siento pero no tenemos esa tela aunque tenemos otras tambin muy buenas" no hubiera sido una respuesta satisfactoria. Preguntas que sugieran la respuesta. Use estas preguntas para ofrecerle orientacin al cliente con pregunta como la siguiente: Prefiere una mquina que pueda reparar usted mismo o tener un contrato de mantenimiento? En forma muy parecida a lo que hace un abogado al interrogar de nuevo a un testigo, el vendedor puede descubrir lentamente los hechos en un proceso de determinacin. En tal situacin, un vendedor trata de que el cliente se percate de sus necesidades personales, necesidades que a menudo ni siquiera l mismo conoce. Hay dos modos de formular las preguntas que sugieren la respuesta. No es...?, como en la expresin " Bo, es esa una excelente mquina ?". Al encontrar un rea de acuerdo mutuo, el vendedor estar en condiciones de averiguar las necesidades del cliente. Por ejemplo, si hubiera dicho "Creo que sta es una mquina excelente", no habra pedido la aceptacin, sino que hubiera expresado su opinin personal, la cual no guarda relacin con la venta y hasta podra suscitar el rechazo del cliente. Qu cosa...?, como en la pregunta: "Qu cosa prefiere un mantenimiento o un alto volumen?". Al ofrecer al cliente una opcin, un vendedor puede determinar qu factores son los aspectos para el cliente y entonces estar en condiciones de determinar de inmediato las necesidades o deseos del cliente. A semejanza de la persona que vende vestidos y pregunta. Elegante o deportivo? De color claro u oscuro? De lana o de algodn? De manga larga o corta?, est eliminando la resistencia a la indecisin del cliente y obteniendo la decisin inmediata del cliente. Hay precauciones que han de tomarse cuando se utiliza el mtodo de preguntas que sugieren la respuesta. El cliente tiende a sentirse presionado si el vendedor insiste en servirse de este tipo de preguntas. Por consiguiente, se procurar no formularlas de una manera insistente o agresiva. En su libro titulado Salesmanship, Willar M. Thompson afirma que las preguntas son herramientas de precisin para descubrir las necesidades de los clientes y deben utilizarse con habilidad y conocimiento". Y procede a enumerar seis pautas que deben tenerse presentes cuando se hacen preguntas:
1. Un solo tema. Cada pregunta debe contener una idea solamente. Debe ser clara, breve y sin digresiones. 2. De respuesta fcil. Se formulan preguntas que el posible comprador conteste con facilidad. Esto ayuda a
reforzar su seguridad en s mismo y le permite tomar una decisin de compra.
Pg. 154 de 200
3. Sin la intencin obvia de vender. nicamente se explorarn posibilidades de la presentacin, pero sin
realizarla. Esto es como una exploracin previa a la perforacin en un campo petrolfero, efectuada para determinar si debe realizarse la perforacin y tambin saber cundo y cmo.
4. Impersonales. Se harn slo preguntas impersonales. 5. Corteses. Slo se hacen preguntas debidamente formuladas para que los posibles clientes respondan de modo
favorable.
6. Oportunas. nicamente se plantearn al inicio de la presentacin. Un vendedor conocedor de la necesidad de
hacer las preguntas en el momento adecuado no esperar hasta la mitad de la entrevista para hace r preguntas correspondientes y correr el riesgo de una respuesta negativa.
DETERMINACIN DE LA SITUACIN DEL CLIENTE

La pelcula se adentra en los detalles concernientes a las cuestiones fundamentales de la situacin y circunstancias en que se encuentra el cliente, recomendando que es imprescindible investigar tres cosas y luego comprobarlas, a saber: 1. Autoridad para comprar 2. Capacidad de pago 3. Competencia Como se seal al hablar del precontacto, hay casos en que el vendedor podr reunir esta informacin antes de la entrevista, pero habr otros en que eso no ser posible y entonces se ver obligado a hacer esas determinaciones cuando se encuentre con el cliente.
LA COMPETENCIA.
El vendedor debe tratar de averiguar lo ms posible sobre la relacin del cliente con la competencia: Qu servicios utiliza, si est satisfecho con el trato y cmo puede competir l en esta situacin? Recurdese que el vendedor quiere encontrar a un cliente insatisfecho con el estado actual de las cosas. Esa persona ser susceptible al cambio, en especial si la presentacin se realiza de manera que aproveche la insatisfaccin de ella. Adems, si el vendedor averigua que un cliente est totalmente satisfecho en una relacin muy estrecha con un competidor, ser mejor que termine cuanto antes la entrevista y explore posibilidades ms prometedoras. El cliente apreciar eso. MANUAL TCNICO PMI - IT
EL PROCESO DE COMPROBACIN.
Se trata de una tcnica reciente que ha resultado de gran utilidad en la realizacin de una venta. Esta tcnica incluye resumir los puntos en forma de preguntas, ms o menos como lo hace el abogado que vuelve a interrogar a un testigo.
Pg. 155 de 200
Cuando se present su producto, cada vez que ella aceptaba un punto, se creaba lo que en realidad era un contrato verbal de sus necesidades. Una vez que un vendedor consigue el asentimiento del cliente, se habr facilitado enormemente su trabajo de ventas.
EL MANEJO DE OBJECIONES
Las opciones del cliente son a la vez un obstculo y una ayuda para el vendedor profesional. Son un obstculo porque interrumpen el flujo de una presentacin de ventas bien planeada. A veces tambin son tiles porque pueden darle informacin vital para la venta: la clave de la venta.
"En realidad eso no es lo que tenamos en mente..." "No es lo que necesitamos". Lo siento, no nos interesa."
EL MANEJO DE OBJECIONES comienza con frases semejantes a las anteriores. Los vendedores las reconocern como algunas de las objeciones que presentan los clientes. Se han examinado algunas tcnicas generales recomendables para tratar con diferentes tipos de personalidad. Adems hay otras tcnicas especficas que han dado buenos resultados a travs de los aos y que son indispensables para que el vendedor est preparado ante lo inesperado. El trato exitoso del cliente difcil se reduce al conocimiento de los puntos importantes: primero, el vendedor debe entender el proceso de ventas y lo que hace que la gente compre. Necesita conocer profundamente el producto y saber la razn por la cual el cliente quiere comprarlo. Segundo, debe establecer un objetivo y no perderlo de vista. Mientras sepa a dnde se dirige, no importa hacia dnde trate de conducirlo el cliente. Por ltimo, debe ser flexible y tener la capacidad de ver la situacin eficientemente sin olvidar los intereses del comprador. Adems de estos puntos generales hay varias y eficaces tcnicas de ventas que preparan a los vendedores para responder casi a cualquier objecin. LA REFUTACION DIRECTA. Es muy til cuando se trata de una pregunta que exija una respuesta inmediata. Si el cliente le pregunta " Por qu debo comprar su producto si estoy satisfecho con la marca X ?. Un vendedor puede contestar diciendo: "Porqu nosotros le damos un 42% de margen de ganancia, mientras que la marca X le da un 38%..." Esta tcnica se recomienda slo cuando el vendedor cree que la objecin del cliente merece una respuesta inmediata. En el ejemplo anterior, si la objecin hubiera sido de menor importancia, se habra evitado las consecuencias de un enfrentamiento directo. Como la refutacin directa es de naturaleza correctiva, se necesita un tono informativo y agradable: un tono de discusin podra darle apariencia de presin a la venta y produce demasiada resistencia.
LA TECNICA SI... PERO
Pg. 156 de 200
Consiste en que el vendedor est de acuerdo con la objecin del cliente, pero la refuta con informacin adicional. " Es cierto, nuestra lnea es ms cara, pero tambin es el nico producto hecho a mano que tiene ese precio". La ventaja de esta tcnica es que coloca al vendedor y al comprador en el mismo nivel y as evita que entre ellos haya una relacin de adversarios, parecida a la que resultara de la aplicacin de la tcnica de la refutacin directa.
LAS PREGUNTAS COMO REACCIONA A LAS OBJECIONES

Con mucha frecuencia, solamente un " Por qu ? " resulta muy eficaz como reaccin ante las objeciones porque trae consigo otras reflexiones del comprador, que ayuda al vendedor a llegar a una conclusin sobre los intereses del cliente, as se cambian los papeles entre el vendedor y el comprador porque las preguntas obligan al segundo a justificar sus objeciones. La compaa 3m ensea a sus representantes de ventas que cuando un cliente slo aporta objeciones negativas a la venta, el vendedor debe responder con preguntas que introduzcan factores positivos a la presentacin. Por ejemplo, si un cliente se queja del precio del producto, el vendedor puede contestar que esto se debe, en parte, a la gran cantidad de propaganda a nivel nacional que se le ha hecho y cuyos beneficios deben ser conocidos por el cliente. El director de capacitacin de 3m dice: "Creemos que ste es un aporte importante en el proceso de formulacin de preguntas y surte mucho efecto para cambiar las respuestas negativas del comprador".
LA PARAFRASIS
La parfrasis o repeticin de la objecin, es de gran utilidad y ofrece muchas ventajas. El vendedor suaviza la objecin porque puede hacer que parezca demasiado dogmtica, hipcrita o poco razonable. As, el cliente la modificar y la har menos vlida. " De modo que mi producto es ms caro que el de la competencia..."
LA TECNICA DEL CAMBIO POSITIVO O BOOMERANG

Tcnica del cambio positivo se llama la del "boomerang", es decir, la de transformar la objecin del cliente en la razn para comprar. Por ejemplo, si el comprador dice: "El oro de 24 quilates es muy valioso, pero los precios estn subiendo mucho en este momento y no puedo comprarlo", el vendedor puede contestar: "Precisamente porque los precios estn subiendo tanto no debe desaprovechar esta oportunidad". Esta tcnica es muy eficaz especialmente para refutar objeciones relativas a precios y a gastos. El buen uso de estas tcnicas y la eleccin del momento apropiado para aplicarlas dependen de cada vendedor, pero en general la parfrasis parece ser la ms idnea para el vendedor moderno. Los psiclogos dicen que casi ninguna tcnica es tan eficaz para crear una comunicacin clara y objetiva entre dos personas. Por ejemplo, cuando el representante de ventas recurre a la refutacin directa, probablemente le resultara mejor repetir la objecin con sus propios trminos: as evita provocar indignacin en el cliente. Si acta de otra manera, tal vez resulte cierto el adagio de que "ganar la batalla pero perder la venta". ADVERTENCIA PARA LOS REPRESENTANTES DE VENTAS Se advierte sobre los peligros que pueden precipitar la prdida de control en la situacin de ventas, especialmente con un cliente difcil.
NO INTERRUMPA, ESCUCHE !
Si el vendedor interrumpe slo lograr irritar al cliente. Quiz no haya entendido lo que el comprador quiso decir, especialmente si ste no tiene la facilidad de la palabra. Si lo hace, habr perdido la venta y no habr descubierto la razn real de la objecin.
Pg. 157 de 200
NO SE EXTIENDA DEMASIADO EN LAS PREGUNTAS Y LAS OBJECIONES

Algunas veces, el conocimiento profundo del tema puede hacer que el vendedor se extienda demasiado en sus respuestas a las objeciones, lo cual aumentar la resistencia del cliente. Siempre evale una pregunta antes de contestarla y recuerde que el cliente suele quedar contento con respuestas cortas y sencillas.
EVITE LAS DISCUSIONES

Muy pocas veces, uno de los que discute logra convencer al otro: las discusiones slo producen una actitud defensiva. Aunque el vendedor cree tener la razn, si permite que surja la discusin, habr perdido la venta porque, generalmente el que pelea no vende.
NO SE MUESTRE SUPERIOR
Esto desilusiona al cliente rpidamente.
NO PIERDA EL HILO DE LA DISCUSION

Como se dijo en la seccin anterior, algunos clientes tratarn de desviarlo de su objetivo de la venta. Si esto ocurre, la presentacin coherente ser difcil. Despus de cada respuesta que el vendedor d al cliente, se debe hacer esta pregunta mental:
Fui claro en mis explicaciones?

Inmediatamente ha de regresar al punto bsico y dirigirse hacia el final de la venta.
POR QUE COMPRA LA GENTE

POR QUE COMPRA LA GENTE? es tanto el nombre de esta parte de nuestro curso como una pregunta para cuya respuesta los comerciantes han gastado millones de dlares. Cuanto ms tratamos de analizar las motivaciones de la gente y cuntas ms teoras formulamos de su comportamiento, ms nos damos cuenta de que estamos tratando con individuos que tienen historia y perspectivas diferentes. Sin embargo, para poder tener xito en los negocios, es necesario entender el comportamiento del consumidor. POR QUE COMPRA LA GENTE? examina este asunto haciendo nfasis en las diversas razones psicolgicas que motivan a la gente a comprar en los sitios de comercializacin, ya sean minoristas o industriales. En el mercado minorista, veremos las etapas especficas por las que pasa la gente cuando compra y algunos de los factores que pueden afectar sus decisiones. Tambin veremos la nueva relacin que se ha desarrollado entre el comprador industrial y el vendedor; una relacin que se ha desarrollado entre el comprador industrial y el vendedor; una relacin que augura xitos para el comercio. POR QU COMPRA LA GENTE? Aunque vivimos en una civilizacin construida sobre la base de la compra y la venta, esta pregunta ha rondado una y otra vez en las mentes de todos aquellos que estamos relacionados con el mundo de los negocios. En los das en que todo era ms sencillo, los economistas tenan una clara opinin del porqu: El comprador tiene un conocimiento completo de sus necesidades y elige el producto que le proporcione la mxima utilidad para los recursos asignados. Y as permaneci el pensamiento econmico hasta el establecimiento de la psicologa y la introduccin, por parte de Sigmund Freud, de una visin mucho ms compleja de la motivacin humana: "Somos impulsados por exigencias irracionales...que emanan del inconsciente...y que son, en gran medida, producto de la represin sexual". Otros pensadores refinaron las teoras de Freud, resaltando que la represin sexual no era la nica causa de estas exigencias inconscientes. Cristian Bailey Consultor IT Pg. 158 de 200
Carl Jung "El instinto sexual es slo uno de los muchos que nos presionan a buscar una satisfaccin desde dentro". Abraham Maslow: "Luchamos por satisfacer una jerarqua de necesidades, desde la simple supervivencia hasta la ltima realizacin personal". Este pensamiento transform nuestra manera de ver las necesidades y deseos humanos; apelando a las necesidades inconscientes de la gente, creamos no slo una enorme variedad de productos y servicios, sino una variedad de formas para hacer publicidad. Hoy en da, el comprador potencial es objeto de investigaciones sofisticadas a nuestra disposicin, sabemos realmente por qu compra la gente. Sommerby Dowst, Editor en Jefe de la revista Purchasing duda de " si alguna vez habr una sola teora que incluya todos los propsitos y que sea universalmente satisfactoria sobre la conducta del comprador", ya que estamos tratando con esa criatura tan impredecible que es el ser humano. Pero Dowst nos dice que existe una manera til de mirar el proceso de compra: la visin del comprador como alguien que est atrapado en un complejo proceso de solucin de problemas. La primera etapa en el proceso de solucin de problemas es la de analizar la situacin. Encontramos a El cliente que est de pie con su esposa frente a su carro que se ha parado. Notan que esto les est sucediendo constantemente. La segunda etapa, definir el problema, aparece cuando El cliente decide que es el momento de comprar un automvil nuevo. La tercera etapa en el proceso de solucin de problemas es la de explorar las soluciones alternativas. Observamos a El cliente y su esposa mientras se pasean por la sala de exhibicin de un distribuidor de automviles, con obvio placer. Pero en la cuarta etapa, la de comparar y evaluar las alternativas la complejidad de las opciones puede crear frustracin y ansiedad. Estos sentimientos se ven claramente en el rostro de El cliente, cuando pregunta al vendedor acerca de los diversos modelos. Debido a que muchas de nuestras compras importantes son complejas, a menudo carecemos del conocimiento especial para evaluar la situacin de manera inteligente. Por lo tanto, consultamos, frecuentemente, con alguien que s posea dicho conocimiento: el vendedor. Esto crea otro problema: Cmo vamos a juzgar el consejo del vendedor ? Mientras el cliente se encuentra en una encrucijada entre un carro prctico y econmico y un reluciente auto deportivo color rojo, nos damos cuenta de otro problema: el conflicto de criterios. En el caso, es un conflicto entre sus necesidades, lo prctico y sus deseos, estar a la moda. Antes de aceptar, nos asaltan nuevas dudas. Qu tal si compramos para luego descubrir que haba una mejor oferta en otro sitio ?. En cualquier momento, el proceso de solucin de problemas puede regresar a una etapa anterior. Los vendedores deben comprender que las personas tienen tantas razones para no comprar, como razones para comprar. Y es posible que ni los compradores mismos se den cuenta de estas razones. Debido a que estas razones inconscientes por las cuales compramos. Por ejemplo, a menudo deseamos que lo que compramos refleje la imagen que tenemos de nosotros mismos. Queremos que un producto que compramos diga algo de cmo deseamos que nos miren. Teri Ralson, agente de bienes races, nos dice que comprar una casa es una " situacin cargada de emociones. Aunque los compradores lleguen a su oficina con una lista de especificaciones prcticas, al final tienden a tomar su Cristian Bailey Consultor IT Pg. 159 de 200 MANUAL TCNICO PMI - IT
decisin con base en si la casa refleja la imagen de lo que desean proyectar. Se nos dice que la compra industrial difiere psicolgicamente de la compra minoritaria porque nuestras decisiones estn menos afectadas por factores subjetivos tales como la auto imagen. Pero al igual que en la compra minorista, la sofisticacin tecnolgica en el campo industrial hace que el comprador dependa cada da del vendedor profesional. Actualmente, y con mucha frecuencia la relacin entre el comprador industrial y el vendedor es similar a una sociedad, en donde el vendedor acta como un consultor. El comprador lleva la gran responsabilidad sobre sus hombros y puede considerrsele como alguien que est envuelto en un complicado proceso de toma de decisiones con mucho que arriesgar en el resultado. Al igual que el comprador minorista, el comprador industrial puede estar buscando un producto ideal o una solucin ideal para resolver un problema. Sin embargo, es necesario reconocer que, no importa cul sea el problema, esta solucin ideal es ilusoria. Si alguien hiciera un producto perfecto, no habra productos competitivos que lucharan por su participacin en el mercado. Por lo tanto, el vendedor debe compartir el proceso de toma de decisiones con el comprador industrial. Al consultar con el comprador, tiene la oportunidad de redefinir el problema y ayudar a facilitar la decisin del comprador. Debe el cliente confiar en la objetividad de vendedor ? Sommerby Dowst afirma que "ganarse la confianza del comprador es el fundamento ms importante." Uno de los aspectos ms difciles de un trabajo de ventas es convencer al comprador de que no estamos ah para explotarlo sino para ayudarlo. Los ganadores de una eleccin realizada recientemente por la revista Purchasing para determinar los diez primeros vendedores industriales de la nacin reafirman que la honradez y la preocupacin por parte de los vendedores son la clave para el xito de las ventas. Estos ganadores recalcan que el comprador de hoy busca a alguien que sepa resolver problemas. Vemos a El vendedor resolver problemas de El cliente con la unidad empacadora mediante una pequea modificacin, aunque es aparente que podra haberle vendido El cliente una nueva empacadora ms costosa. Esto ilustra la funcin del vendedor como un solucionador de problemas y o como un manipulador. Por qu compramos? Tenemos deseos y tenemos necesidades. Si deseamos algo lo suficiente, puede llegar a convertirse en una necesidad. El cliente invita al vendedor a almorzar y se van en su carro nuevo. Es el auto deportivo rojo, reluciente, que El cliente haba deseado tanto. Por qu escogemos un producto y no otros? Puede ser por razones funcionales o puede ser porque el producto dice algo sobre nosotros. Por qu compramos de un vendedor y no de otro? Es cuestin de confianza.
EL PROPOSITO BASICO DE UN NEGOCIO ES CREAR UN CLIENTE

Como lo dijo una vez el experto en administracin, Peter Drucker, el propsito bsico de un negocio es crear un cliente. Pero hoy, a pesar de toda la tecnologa sofisticada con que contamos, todava no sabemos mucho acerca de lo que motiva su conducta de compra. Ms an, en los ltimos aos, hemos presenciado un distanciamiento entre el comercio y el consumidor, que en ocasiones llega a los lmites de la hostilidad. John A. Howard, experto en mercadotecnia, atribuye esta situacin a " una falta de comprensin de la conducta del consumidor. Obviamente es difcil hablar de ciencia sistematizada cuando se est tratando con la gente, despus de todo, son personas cuyas necesidades y motivaciones no son realmente controlables. Sin embargo, se haban hecho algunos intentos por elaborar teoras generalizadas que puedan ser tiles al enfrentarse a la conducta de la compra de la gente. MANUAL TCNICO PMI - IT
Pg. 160 de 200
En la siguiente seccin las analizaremos, examinaremos aquellas que se relacionan con los compradores en general, con los compradores minoristas y con el comprador industrial.
COMO COMPRA LA GENTE

Ya sea que nos encontremos en el campo minorista o industrial, el proceso de compra es el mismo. Como decamos en la pelcula, es esencialmente igual proceso de solucin de problemas, Propuesto por John Dewey en 1,910. En esa poca, Dewey sugiri que existan cinco etapas en el proceso: 1. Se siente una dificultad 2. Se localiza y define la dificultad. 3. Se sugieren posibles soluciones. 4. Se consideran las consecuencias. 5. Se considera una solucin. Dewey tambin anot que, en cualquier momento durante el proceso de solucin del problema, podramos regresar a una etapa anterior o incluso saltarnos un paso por completo. La teora bsica de Dewey se utiliza hoy todava. Sin embargo, se ha agregado un paso: 1. Analizar la situacin. 2. Definir el problema. 3. Explorar las soluciones alternativas. 4. Comparar y evaluar la alternativa. 5. Llegar a una solucin. 6. Resultado de una solucin. La adicin del sexto paso ha constituido una importante revisin de la teora. Cuando se aplica al concepto de compra minorista industrial explica un cambio importante que ha afectado la industria de las ventas en los ltimos aos. Este cambio refleja una relacin creciente entre el comprador y el vendedor. Hoy, el resultado de una decisin de compra es tan importante para el comprador y se considera el comienzo ms bien que el final de la relacin. En razn del concepto del riesgo percibido; que afirma que el comprador sabe que una vez que se ha hecho la compra es l quien debe enfrentarse a las consecuencias, buenas o malas, es importante que participemos en el proceso de toma de decisiones con los compradores desde las primera etapas. Intentamos reducir al mnimo el riesgo percibido, aparente, compartiendo la toma de decisiones con ellos, y por tanto, ellos se tranquilizan al saber que nosotros tambin compartiremos el resultado de su compra. Por ejemplo, podemos asegurarles que pueden devolver un artculo si no estn completamente satisfechos con l; o a nivel industrial, podemos decirles que vendremos a revisar la efectividad de nuestro equipo. Al hacer lo anterior, tambin reducimos las probabilidades de que aparezca mayor de los obstculos que puede surgir cuando trabajamos con nuestros clientes en la solucin de problemas: el problema de confianza. Mientras Cristian Bailey Consultor IT Pg. 161 de 200
ayudamos a nuestros compradores, con frecuencia pueden preguntarse si estn siendo manipulados; despus de todo, s tenemos algo que ganar de ellos. Debemos recalcar que lo que nosotros ganamos es el hecho de tenerlos como clientes, y no el dinero que provenga de una compra individual. Por lo tanto, el entrar a participar con el cliente desde el inicio del proceso va a ser de beneficio para nosotros. Debemos ayudarlos a definir el problema real y luego debemos tratar de ayudarlos a resolverlo, pues al hacerlo creamos una relacin que va a ser satisfactoria para los dos.
COMPRAS AL POR MENOR

Qu es lo que motiva al comprador? Ha probado ser ms fcil determinar por qu la gente va de compras, por qu compra y esta informacin nos ayuda a comprender la conducta y actitudes del consumidor. Dorothy Cohen, en Consultor Behavior, ha presentado la hiptesis de que hay dos motivos que estimulan a los consumidores a ir de compras: motivos personales y motivos sociales.
MOTIVOS PERSONALES
Desempeo de una funcin. Se considera que ciertas actividades son del dominio de ciertas funciones dentro de la sociedad; por ejemplo, tradicionalmente, se ha considerado que hacer mercado es una tradicin del ama de casa. Diversin. Algunas veces nos gusta " curiosear " y encontramos que ir de compras es un cambio agradable en nuestra rutina diaria. Se ha encontrado que esta actividad predominante se lleva a cabo en centros comerciales modernos. Auto-gratificacin. Cuando nos sentimos algo deprimidos, con frecuencia es satisfactorio salir y comprarnos algo para celebrar algn logro. Conocer las nuevas tendencias. A los que nos gusta mantenernos enterados de las ltimas tendencias de la moda nos motiva mucho salir de tiendas para siempre adelantarnos a los dems y ser siempre los primeros en estar al da con la moda. Actividad fsica. Desde que comenzaron los nuevos centros comerciales, muchos de nosotros, especialmente los mayores y los jvenes salimos de tiendas simplemente para tener un estmulo fsico. Estmulo sensorial. Muchos de nosotros nos vemos atrados por la vista, los sonidos, los olores que emanan de las nuevas experiencias de compra. A medida que os expertos en mercadotecnia se vuelven ms sofisticados, aprenden a atraernos a muchos niveles.
MOTIVOS SOCIALES
Las experiencias sociales fuera de casa. El ir de compras puede darnos la oportunidad de encontrarnos con amigos y de conocer otras personas. Algunas personas opinan que una experiencia de compras es una forma eficaz para combatir la soledad. Comunicarse con otros que tengan intereses similares Algunas tiendas se especializan en productos y servicios para pasatiempos o profesionales en particular y, por lo tanto, pueden servir de punto focal de interaccin para aquellos que compartan una especialidad; por ejemplo, las libreras, las tiendas fotogrficas, los almacenes de artculos deportivos, etc.
Pg. 162 de 200
Atraccin para grupos de inters comn. Podemos tener el deseo de aprovechar una idea de compras para estar con nuestro grupo de compaeros o con un grupo al que deseemos pertenecer. Por ejemplo, vemos grupos de adolescentes en los almacenes de discos. Otras personas pueden sentir satisfaccin al comprar en tiendas muy costosas, aun cuando no puedan darse ese lujo; satisfacemos una necesidad si sentimos que podemos subir en la escala social. Status y autoridad. Uno de los aspectos ms satisfactorios de salir de compras es que nos brinda la oportunidad de exigir atencin y respeto: " el cliente es el rey. El placer de regatear. Mientras muchas de las personas que salen de compras consideran que regatear es de mal gusto, hay algunas que realmente disfrutan del proceso, creyendo que estn recibiendo una "ganga". Lo ms valioso de las hiptesis de Ohen es lo que nos dicen sobre la mercadotecnia y el servicio al cliente. Cualquier enfoque orientado hacia el producto, ya sea en una exhibicin dentro del almacn, una oferta especial o una promocin, puede ser duplicado por la competencia. Sin embargo, la satisfaccin de estos motivos de compra nos brinda la oportunidad de ganar una ventaja en el mercado y de crear una relacin continuada con el comprador.
COMPRA INDUSTRIAL
Una "sociedad" para la solucin de problemas Los cambios que se han operado en aos recientes en el mercado industrial han sido extraordinarios. Las tcnicas de ventas se han mantenido al ritmo de la rpida expansin tecnolgica. El vendedor de hoy debe hacerse indispensable para el agente de compras.
En primer lugar, se espera que a nosotros como vendedores estmos no slo familiarizados con todos los detalles de nuestro producto o servicio, sino que tambin debemos conocer muy bien el negocio del comprador. De hecho, ha habido circunstancias en las cuales los vendedores han ayudado a los gerentes en emergencias que se han presentado en lneas de ensamblaje, en sitios de construccin y en las cocinas de los restaurantes. La distincin entre el vendedor y el profesional ya no existe porque el vendedor industrial hoy es un profesional. Lo ideal sera que supiramos ms de nuestro campo que el comprador, an cuando dicho campo sea el negocio del comprador. La experiencia y la destreza nos permiten convertirnos en el "socio" del comprador. Tal como dice la pelcula, debemos considerar al comprador como "alguien que est arriesgando mucho...su carrera, su reputacin, su autoestima y un sentido muy real de responsabilidad por el bienestar de toda la organizacin y cada uno de sus miembros. Estas influencias colocan mucha presin sobre los compradores y es nuestro deber ayudar a aliviarles esta carga tanto como nos sea posible, ya que esto se revertir en beneficio directo para nosotros. De esta manera ganaremos su respeto y confianza. Si no ayudamos al comprador y el resultado es un fracaso y la prdida del empleo, estaremos en una situacin desventajosa, pues nos vemos obligados a comenzar de nuevo y crear una nueva relacin con un nuevo comprador. Es una ventaja para nosotros comprometernos con los clientes desde las primeras etapas de la tomas de decisiones o de la solucin de problemas. De otra manera, pueden hacerse a una idea fija, lo que puede crear obstculos adicionales. Debido a nuestro conocimiento especial, podemos descubrir que, a menudo, nuestros clientes no reconocen el problema real, sino que estn abordando un sntoma o problema secundario. Nuestra capacidad para entrar a redefinir un problema nos proporciona una clara ventaja; nuestros clientes nos van a considerar como alguien que les ha aliviado la carga, alguien que est ah para facilitar su toma de decisiones, un consultor externo. Tal como lo seala la pelcula, existe un peligro inherente al tratar de establecer este tipo de relacin con nuestros clientes; el peligro de aparecer como un manipulador o explotador. Si tratamos de explotar a nuestros compradores, eventualmente ellos se darn cuenta de este hecho y perderemos nuestra relacin con ellos. Y, como vendedores
Pg. 163 de 200
industriales, nuestra meta ms importante no debe ser la venta rpida y lucrativa, sino ms bien la relacin ms lucrativa a largo plazo. Por lo tanto, en todo momento, debemos recalcar nuestra objetividad ante los clientes. Una vez ms, nuestros productos o servicios no son necesariamente muy diferentes de los de la competencia. Lo que est en juego es nuestra propia persona y eso es lo que hay que ofrecerle al cliente. Como deca un agente de ventas: " No resisto a los representantes de ventas que tienen una idea nueva una vez por la cuaresma; me gustan los vendedores que puedan estar dando ideas nuevas en forma continua, al igual que suministran productos; representantes que me puedan ayudar a resolver mis problemas de negocios". Lo que los compradores buscan hoy son ideas que los ayuden a reducir sus costos y sus gastos generales; ideas que manejen los problemas de la inflacin y la recesin. Y, por supuesto, deseen mantenerse un paso adelante de la competencia. Nuestra labor consiste en producir ideas, en ser solucionadores de problemas. Si podemos hacerlo, ganaremos la confianza y los negocios de nuestros clientes.
SOY TU CLIENTE: RECUERDAME

Soy tu cliente... Recurdame Querido trabajador Te acuerdas de m?. La otra vez visite tu empresa, cada que te visito me gusta que me recuerdes y me saludes con amabilidad y cortesa. En otras palabras, quiero que me hagas sentir a gusto e importante. Quiero decirte que a veces espero con paciencia, aunque s que no es realmente necesario. Pero me haces esperar. Te pido de favor que no dispongas de mi tiempo. Se que tu trabajo es muy intenso y siempre ests ocupado pero, quisiera que me tomes en cuenta en todo momento y que me pidas consentimiento si debo esperar. No me gusta que interrumpas mi asunto cuando me atiendes para dar preferencia a otros; apelo a tu buen criterio y que sepas dar prioridades a tu trabajo, si me pones a m en primer lugar mejor -. Edcanos a nosotros tus clientes cuando debemos esperar nuestro turno con cortesa y buen tacto. Pienso que cuando te vuelvo a ver recordars que he sido tu cliente durante mucho tiempo. Cuando trato un asunto contigo pienso que me recordars. No me hagas volver a repetirte infinidad de veces lo mismo. Cuando lo haces, me parece que nunca te he interesado y que no tengo esperanza de que resuelvas mis necesidades. He querido conocer tu empresa, comprar aqu y me gustara que me trataras como alguien importante para ti y para tu empresa. Recurdame por favor, - no me digas mentiras -. No me digas que espere un segundo, no me digas que me llamars ms tarde, no me ordenes que te espere - pdeme consentimiento -, si haces un compromiso conmigo por favor cumple; mantenme informado del avance de mis asuntos y por favor infrmame bien de los, trmites o requisitos que debo cumplir: no me hagas dar vueltas innecesariamente. No le des prioridad al telfono cuando me atiendes, yo me tome la molestia de estar ah la otra persona no. Voy a tu empresa porque para mi es prctico, me gusta entrar aqu, me queda cerca, encuentro lo que necesito, son muy buenos los servicios y productos que ofreces, las instalaciones son adecuadas y funcionales, un ambiente agradable, tienes un amplio prestigio y equipo moderno, encuentro lo que necesito, tu empresa promete mucho con la gran publicidad nacional y local, etc.. Por favor no me hagas cambiar de opinin con tu psimo trato o indiferencia. S que tienes problemas como toda la gente porque tambin eres humano. S que t cansas o que estas muy ocupado, pero comprende que debes superar todo eso por ti mismo. Yo soy tolerante contigo pero hasta cierto punto. Algunos clientes se enojan ms rpido que yo; pero yo tambin me s enojar, por favor no llegues a ese lmite. Puedo no manifestarte lo que pienso de ti, pero me quedo con un sentimiento muy profundo que posteriormente puede ser mi motivo para cambiar de empresa. Quiz no te lo diga, pero puedo despedirme de ti con una gran frustracin por tu proceder.
Pg. 164 de 200
Los empleados son objeto de muchas presiones, pero es parte de tu trabajo. Debes manejarte con profesionalismo y con madurez, se es t reto. No puedes pasarte el tiempo en crisis!. De lo contrario no mereces ocupar el honroso puesto que tienes. Te tolerar por ahora, pero no te equivoques. A la larga yo voy a ganar. Sabes porqu?. Porque existen muchas otras empresas que se pelean porque yo sea su cliente y estn dispuestos a darme lo que tu no has sido capaz de darme: cortesa y atencin. Necesito, que cuando vaya a tu empresa, me encuentre a un trabajador sonriente que manifieste que est contento con su trabajo; a travs de sus actitudes, modales, forma de mirar, la forma de platicar conmigo, la forma de interesarse en mis necesidades y la forma de ayudarme a solucionar mis problemas; que me haga sentir bienvenido y confortable desde que llego hasta que me voy. No me hagas sentir solo un "nmero de cuenta", soy tambin una persona como t. Me decepcionas cuando me dices: No s!, No est la persona encargada!, No tengo los datos!. Que no tienes que ver en el asunto! , No s a que hora llega!. No hay!. Por favor intersate en mi asunto y dame una alternativa, aunque no seas directamente responsable de atenderme. Quiero tener una buena imagen de todas las personas laboran ah. Me molestas cundo: No conoces lo que ofreces!, Tienes desordenada tu rea de trabajo!, No me haces caso!, Me haces esperar!, Te pones a platicar con tus compaeros cuando me atiendes!, Gritas o utilizas palabras inadecuadas!, Eres vulgar!, Eres confianzudo conmigo!, No me tienes consideracin!, Te crees muy autosuficiente!, No me dejas hablar con libertad!, Te desesperas cuando me atiendes!, Me presionas a tomar una decisin!, Me quieres ofrecer algo que no me convence!, T molestas por mi inseguridad!, Te vistes mal o que tienes malos hbitos de higiene personal!. Atiendes a un conocido tuyo que no espero su turno!. Se que para ti es muy importante tu trabajo y procuras conservarlo. Pero espera, para m es importante el asunto que quiero tratar contigo y necesito recibir de ti lo que espero. No me hagas arrepentirme de haber estado contigo. Recuerda que despus de mi visita a tu empresa hago un anlisis de todo lo sucedido y no te quiero responsabilizar por algn malestar. RECUERDA QUE ME CONFORMO CUANDO ES NECESARIO PERO, ESO S, NUNCA OLVIDO. TOMO EN CUENTA TODO LO SUCEDIDO PARA DECIDIR MI PROXIMA VISITA A TU EMPRESA. Tu empresa promete un buen servicio por el que estoy dispuesto a pagar. Puedo perdonar tus errores pero no tus ACTITUDES. De veras que aguanto mucho: descortesas, falta de consideracin, tu mal carcter, tus frustraciones, tus complejos y hasta tu estupidez. Pero no se te olvide. Aunque no te lo diga, a veces puedes decepcionarme. Pero el gusto que me da es que siempre gano, solo porque s que no debo ser tu cliente, ya s que nadie me obliga a tratar contigo; s que puedo ir a donde se interesen realmente por m Y, sabes porqu? soy nada menos y nada ms que EL CLIENTE. Tengo tanto poder que no te imaginas. Puedo destruir tu imagen en menos tiempo del que tardaste en formarla. Puedo opinar con mis amigos acerca de ti y destruirte antes de que te conozcan. Puedo hacer de ti algo indeseable y negativo para todos mis colegas: LOS CLIENTES. Con mi indiferencia har angustiosa tu espera de que llegue a utilizar tus servicios pero no me volvers a ver. NUNCA TE DIRE QUE ES LO QUE ME MOLESTO, SERA TU PROBLEMA SABERLO. HAY MUCHAS EMPRESAS A DONDE YO PUEDO IR Y QUE REALMENTE QUISIERAN ATENDERME. Los clientes como yo, ya tenemos suficientes problemas como para que un TRABAJADOR COMO TU sea tambin un problema. Si no hay un buen servicio, me voy. No alego, no me quejo, no me exalto. Solo nunca regreso y. YA! Eso no es todo, como cliente me comunico con los dems, COLEGAS LOS CLIENTES, acerca de tus fallas Y MAL SERVICIO, tus descortesas, tus actitudes. De modo que no te conviene tenerme como tu enemigo. Puedo hacer una labor discreta y lenta para destruir tu imagen y la de tu empresa. Cuando fracases te preguntars: En qu fall?. Simplemente porqu nunca me tomaste en cuenta. Preferiste tu forma de ser, Preferiste tus intereses, Preferiste actitud y tus ideas. Ahora vndete tu solo. LOS CLIENTES COMO YO NOS ENCONTRAMOS HAMBRIENTOS DE UN BUEN SERVICIO. Cristian Bailey Consultor IT Pg. 165 de 200
Cuando encontramos empleados eficientes, corteses, bien capacitados, que miran a los ojos y que hacen algo extra para complacernos. Nos sentimos con deseos de regresar. A veces por el mismo trabajador que nos atiende. a pesar, a veces, de la misma empresa. Si me tratas como persona, yo te tratare igual. Quiero seguir contigo y mantener una buena relacin de amigos indefinida. Aydame a lograrlo. Siempre que me recuerdes a m, yo te recordare a ti, con afecto: Tu Cliente
Soy tu cliente... recuerdame

Diariamente se gastan fortunas en publicidad por parte de los miembros de industrias similares, como bancos, almacenes minoristas, cadenas de restaurantes de servicio rpido, etc. que ofrecen bsicamente los mismos productos y servicios que sus competidores directos. Sin embargo, suele desperdiciarse el dinero gastado en publicidad debido a una falla de actitud que ocurre en el punto vital de contacto entre el negocio y el mercado: la interaccin "uno a uno" entre el vendedor y el cliente. La investigacin reciente demuestra que un cliente insatisfecho le comunicar su insatisfaccin por lo menos a nueve de sus amigos... quienes, a su vez, se la contarn a otros... y stos a otros. No se trata slo de una cuestin de mensajes publicitarios costosos que fallan por llegar a odos que han escuchado historias negativas acerca de una compaa; los tribunales le otorgaron hace poco $150,000 a un cliente disgustado por la descortesa de un dependiente...que no se mostr abusivo ni equivocado... simplemente fue descorts. RECUERDAME ofrece una visin rpida y descarnada de varios ejemplos tpicos de la interaccin vendedor-cliente. Sin adornos, RECURDAME ilustra este hecho fundamental: No se trata ni siquiera de si el servicio que desea el cliente puede ser prestado o no. Eso no es lo ms importante. Lo que realmente cuenta es la ACTITUD con la que se trate al cliente.
PUNTOS PARA INICIAR LA DISCUSION

1. Qu es ms importante en la mayora de las interacciones diarias entre el que presta el servicio y el cliente: el servicio prestado o la actitud de la persona que presta el servicio? ...La actitud puede ser lo ms
importante porque, incluso, si por alguna razn fuere imposible prestar el servicio, la actitud interesada de la persona que est encargada de prestar el servicio puede mitigar las circunstancias y retener al cliente para servicios futuros... Por otra parte, incluso si se presta el servicio en la forma especificada, una persona desinteresada puede impedir que el cliente regrese.
sus servicios? ...Sera posible que una persona que prestara un servicio y simplemente tuviera una actitud de inters, diera una actitud diferente? De ser as, qu es lo ms importante a la larga para el cliente: la actitud o el verdadero inters?
2. Cules son algunas de las formas en las que una actitud de verdadero inters puede ser demostrada por la persona que presta el servicio? ...En qu forma comunican sus actitudes algunas de las personas que prestan
3. Cmo puede la persona que presta un servicio desarrollar un actitud de verdadero inters?..Es
importante que la persona que presta el servicio procure siempre ponerse en el lugar del cliente?
4. La " despersonalizacin " que existe en la actualidad podr ser el resultado de la expansin de los negocios o ser tal vez debida a que las personas que prestan los servicios no se preocupan realmente por sus clientes?
Pg. 166 de 200
5. Cmo puede transmitir la persona que presta el servicio una actitud de verdadero inters? Qu significa
realmente servir con una sonrisa? ste viejo lema tiene ahora una importancia mayor o menor?
6. Cmo se crea una atmsfera de confianza o desconfianza? ...Qu podra hacer un trabajador para cumplir
con su trabajo con calidad y no crear una atmsfera una negativa?
7. Cuando la persona encargada del mostrador de alquiler de autos llam al garaje para informar que tena un cliente que "deca que haba reservado un auto, Qu impresin le dio al cliente en cuanto a la confianza que le tena? ...alguien en el auditorio puede ofrecer un ejemplo de lo que alguna vez le puede haber dicho un
dependiente?
8. Qu tipo de ejercicios diarios u horarios podran hacer las personas que prestan servicios para entrenarse mentalmente a tener una actitud de verdadero inters?
VENTAS CON EXITO

RESUELVA MI PROBLEMA Y...! TIENE MI PEDIDO!
Wber define la palabra PROBLEMA como " un asunto sin clarificar que exige una solucin o anlisis y que requiere mucho conocimiento y habilidad para poder drsele una solucin o un anlisis adecuados. Los problemas sin resolver que necesitan una solucin existen en todas las situaciones de ventas y la funcin de sus representantes es la de ser creativos en su trabajo con los clientes para darles una solucin apropiada a estos problemas.
INFORMACIN BSICA
En VENTAS CON EXITO los presentes vieron a tres vendedores experimentados, enfrentados a la misma situacin. Aunque todos se desempearon bien y tuvieron muchos aciertos, algunos vendedores pierden la venta porque no supieron identificar y resolver correctamente los problemas del cliente. Es indudable que la tcnica de solucionar problemas, en lugar de la de su manipulacin tiene el primer lugar en la metodologa de las ventas. Bsicamente, el agente de ventas debe ser un solucionador de problemas. Su xito depende de la capacidad que tenga de darles una solucin, sea sta inmediata o a largo plazo. En esta seccin, se va a examinar dicho proceso y su utilidad en las entrevistas de ventas. Al mismo tiempo, se le va a dar nfasis especial al proceso de la toma de decisiones, el cual tiene una funcin primordial en cualquier venta posible. MANUAL TCNICO PMI - IT
COMO SOLUCIONAR LOS PROBLEMAS

Cuando un agente de ventas est con un cliente, nada debe ser ms importante para el primero que el problema inmediato del comprador. Sus planes deben estar dirigidos hacia darles una solucin: as, crear un proceso que funcionar naturalmente. La experiencia nos muestra que los agentes de negocios tienden a aplazar el enfrentamiento a sus problemas pero, despus de comenzado el proceso, exhiben constancia en su conducta" que los motiva a seguir trabajando en el Cristian Bailey Consultor IT Pg. 167 de 200
problema. Como resultado, si un representante de ventas est listo para ayudar al comprador a solucionar su problema, se puede transformar en una especie de socio para el cliente o para la persona que deba tomar dicha decisin. De acuerdo con esto, el vendedor debe estar alerta para tratar de solucionar las dificultades desde las etapas iniciales de la entrevista, de otra manera, corre el peligro de pasar por alto las soluciones ms obvias. Interprete el caos como un "problema en aumento" en lugar de tomarlo como una situacin que necesitaba una solucin inmediata. El proceso de la solucin a los problemas incluye lo que se puede llamar "el beneficio", es decir, interpretar las cualidades del producto o del servicio en trminos de lo que har por el cliente. Cada vez que se presente la ocasin, el vendedor debe estar en capacidad de resolver los problemas el comprador, estn o no relacionados directamente con el producto o el servicio que se est prestando. El vendedor expresa su inters por todas las dificultades del cliente y, por consiguiente, est en capacidad de identificar los problemas ms importantes. Otro aspecto importante para poder solucionar los problemas con xito consiste en recordar que las soluciones posibles se presentarn ms claramente si se regresa al punto de partida. Es mucho ms difcil llegar a una solucin si el vendedor se empea en seguir un camino solamente. Si se detiene a considerar la situacin desde diferentes puntos de vista, se observarn varias alternativas. Hay muchas teoras sobre la manera de solucionar los problemas y casi todos parecen llegar a conclusiones similares. En esta gua se van a examinar dos anlisis: la definicin clsica propuesta por John Dewey y otra, relacionada directamente con los negocios, propuesta por Peter Drucker. Dewey propone cinco pasos a seguir en el proceso de la resolucin de problemas:
CINCO PASOS EN LA SOLUCION DE PROBLEMAS 1. Hgase consciente del problema. En la medida en que el representante de ventas perciba una
resistencia del cliente o tenga la sensacin, an vaga, de que su tcnica no funciona, debe aceptar que hay alguna obstruccin en su camino. Puede que la persona no sepa todava en qu consiste el problema pero, por el hecho de reconocer su existencia, puede alterar su tcnica y comenzar a buscar el problema real.
2. Aclare el problema. En el proceso de determinar cul es el agente e ventas debe tener cuidado en no confundir el problema con sus sntomas: de otra manera, correra el riesgo de actuar como el mdico que ataca los sntomas del paciente hasta aliviarlos; pero que, sin embargo, no llega a buscar las causa de dichos sntomas. 3. Proponga hiptesis. El vendedor debe sugerir las ideas o los procedimientos que considere como
conducentes a la solucin del problema del cliente. El representante de ventas no se debe limitar a una solucin nica, si cree que ha descubierto varias salidas posibles para el cliente.
4. Defina las implicaciones de la hiptesis. En conjuncin con el comprador, el vendedor debe

MANUAL TCNICO PMI - IT estudiar los pros y contras de cada solucin posible. Con el mtodo cientfico, no hay razn para llegar a una sola conclusin nica, ya que se pueden examinar varias para determinar su efectividad. Sin embargo, en el campo de ventas, como hay dinero en juego, es ms efectivo llegar a una conclusin final.
5. Pruebe las hiptesis. Esto puede hacerse con un anlisis lgico sin necesidad de recurrir a tesis de
situaciones. Al final del anlisis, el cliente tendr que tomar una determinacin. Hay que recordar que estos cinco pasos analizan solamente las acciones mentales pertinentes y que no han sido enumerados en una secuencia obligatoria. Sin embargo, en caso de duda, se aconseja comenzar de nuevo con el primer punto para lograr mirar el problema desde una perspectiva clara y disciplinada.
Pg. 168 de 200
Richard M. Baker en Salesmanship dice. "En el mercado actual, hay muchos vendedores listos y capaces de enfrentarse a las necesidades del cliente, el cual comprar al que demuestre mayor habilidad para resolver sus problemas en los negocios. Esto lo presenciamos en VENTAS CON EXITO. Peter Drucker nos presenta una gua ms pragmtica:
1. Defina el problema. Qu clase de problema es? Cul es el factor ms importante? Cundo se debe
resolver? Por qu se quiere solucionar? Cunto costar darle una solucin?
2. Defina sus alcances Qu se quiere lograr con la solucin de un problema? 3. Desarrolle otras soluciones posibles. Cul de los planes ofrece la manera ms segura de
evitar complicaciones inesperadas?
4. Sepa lo que debe hacer despus de haber tomado la decisin. Las dos guas
anteriores son muy tiles para analizar lo que sucede, se habr dado cuenta del momento en que fallaron. Los vendedores deben recordar que los clientes tienen que pasar por el mismo proceso de darle solucin a los problemas y, por consiguiente, pueden caer en los mismos errores de los primeros.
Como tomar decisiones

Despus de reconocer el problema y la necesidad de llegar a una decisin, los clientes tienden a seguir un proceso lgico. El vendedor debe entender este proceso para beneficio propio y del cliente. La mayora de los ejecutivos, por intuicin o en desarrollo de un plan trazado, se hacen a s mismos cuatro preguntas durante estos procesos de darle solucin a los problemas y de tomar decisiones:
1. QU RIESGO EST CORRIENDO AL TOMAR ESTA DECISIN? La persona debe pesar las ventajas
y las desventajas para la compaa.
2. ESTA DECISIN VA A SIGNIFICAR EL MENOR ESFUERZO CON LOS MEJORES RESULTADOS
Y EL MNIMO DE PROBLEMAS PARA LA COMPAA? Aqu hay que tomar la decisin segn la cantidad de trabajo que sta va a implicar, es decir, las soluciones deben ir de acuerdo con el problema: no deben ser muy drsticas ni ineficientes.
3. ES EL MOMENTO APROPIADO? Algunas soluciones se pueden aplazar por semanas, meses o aos. En
otros casos, como en el de Molnar, hay que actuar inmediatamente.
4. EXISTEN LOS RECURSOS ADECUADOS, TANTO EL CAMPO FINANCIERO COMO EN EL HUMANO, PARA CUBRIR TODAS LAS NECESIDADES?". De otra manera, no tendra sentido tratar de
efectuar una venta a una compaa que no quiere dedicarle el tiempo o el material humano para facilitar una solucin. Esto sera contraproducente para ambas partes.
Al entender el plan a seguir, el vendedor puede trabajar en grupo con los clientes y seguir un proceso de pensamiento lgico, llamado con frecuencia "pensamiento reflexivo" para llegar a una solucin correcta.
Defina el verdadero problema

Uno de los errores ms comunes de los representantes de ventas es confundir los sntomas con los problemas. La exactitud con que se defina el problema determinar la calidad de las soluciones a que se llegue y esto se reflejar tanto en el comprador como en el vendedor.
Pg. 169 de 200
Algunos vendedores se ven enfrentados a un problema que no entienden o que no saben resolver y tienden a acercarse a l como si lo entendieran y como si tuvieran una solucin a mano. De esa manera, estn trabajando con su propio problema que no entienden o que no saben resolver y tienden a acercarse a l como si lo entendieran y como si tuvieran una solucin a mano. De esa manera, estn trabajando con su propio problema y no con el del cliente: esta es la manera ms fcil de salir del paso. Como resultado. el vendedor est vendiendo algo que le comprador ni quiere ni necesita, y estar, adems, poniendo en peligro la posibilidad de desarrollar una relacin productiva. Es mejor tomarse un poco de tiempo y esfuerzo extras para identificar el problema. Esta habilidad para la identificacin viene de varios orgenes e influencias: las experiencia, el trabajo, la educacin, la habilidad de percibir las relaciones de causa y efecto y la intuicin, sea accidental o por suerte. Sin embargo, la tcnica ms segura es la primera de las guas de Dewey y Drucker: defina el problema. Si el vendedor hace un estudio detallado - la observacin es un instrumento esencial en este caso- de todo lo que puede estar causando la dificultad, podr hacer una separacin entre lo que l cree que constituye los problemas menores y los sntomas para as llegar a la definicin del verdadero problema. Un test bueno de esta definicin se puede lograr si el vendedor es parte de ella para verificar su relacin causal con cada uno de los sntomas obvios. Dar solucin a los problemas es una manera de desarrollar una relacin de negocios. La ventaja de ayudar a los compradores a solucionar sus problemas est en que el vendedor se puede convertir, en esencia, en un socio para el cliente. Esta relacin de grupo permite desarrollar una labor ms efectiva en las ventas. An antes de que stas se sistematizaran, los vendedores eficientes ya estaban trabajando con sus compradores de esta manera pero intuitivamente. As, se desarrolla una buena comprensin del cliente (lo que facilita el trabajo) y el comprador desarrolla un a buena apreciacin y respeto por los servicios del vendedor. No importa cul sea el producto o el servicio, el representante de ventas se puede beneficiar de otras maneras al ayudar a resolver los problemas del cliente; al entender las condiciones y sus necesidades, los vendedores pueden aportar informacin crtica que ir en beneficio de la empresa. Orn Henning, gerente de comercializacin de los productos industriales para la Texas Instruments dice: "Uno debe recordar que las ventas forman parte de la comercializacin. Especialmente en el mundo cientfico-industrial. La comercializacin implica tambin comunicar de nuevo a la fbrica las necesidades individuales de los clientes y sus problemas particulares. Cuando el representante de venta se da cuenta de esto y lo practica, se inicia una visin nueva en el rea de ventas. El representante no se puede dar el lujo de vender solamente un producto -un producto esttico- por lo menos en nuestra empresa."
SERVICIO AL CLIENTE
ESTRATEGIAS PARA EL EXITO
Un buen servicio es la clave para lograr compras repetitivas por parte de los clientes. SERVICIO AL CLIENTE: ESTRATEGIAS PARA EL EXITO es un tema que recalca la importancia que el servicio al cliente debe tener para cualquier organizacin que ofrece sus productos o servicios al pblico en general. La idea central del tema radica en que un servicio eficiente y corts al cliente resulta decisivo para el xito de una organizacin. Cada persona tiene un papel que desempear en el aumento del nivel de satisfaccin del cliente; dependientes, personal administrativo, supervisores y ejecutivos, todos deben estar al tanto de las necesidades de los clientes ya saber cmo satisfacerlas mejor. Hoy en da, el entorno de los negocios es altamente competitivo y cualquier compaa necesita establecer estrechas relaciones con sus clientes con el propsito de conservar su fidelidad. Muchas son las personas que dan por sentado estas relaciones y desconocen los pasos especficos que pueden ayudar a asegurar la satisfaccin del cliente.
Pg. 170 de 200
Esta parte del curso examina el tema, centrando nuestra atencin en los representantes de servicio al cliente, dado que ellos deben resolver los problemas de sus clientes, por telfono, en el campo y en las ventas de mostrador. Mientras se observan sus acciones en diversas situaciones ante sus clientes, se va delineando un modelo de cuatro pasos aplicable a las actividades de servicio a los clientes que funciona como un enfoque sistemtico para proporcionar en toda ocasin un servicio de calidad. El modelo de cuatro pasos que se presenta en SERVICIO AL CLIENTE: ESTRATEGIAS PARA EL EXITO es: 1. 2. 3. 4. Establecer una relacin profesional con el cliente. Identificar las necesidades o problemas del cliente. Proporcionar el servicio acordado. Concluir la transaccin.
Un empleado consciente de su propio comportamiento puede contribuir a una imagen positiva de la compaa, a un ambiente de negocios eficiente y productivo, y al mantenimiento de relaciones perdurables con los clientes.
NUESTRA EXPERIENCIA CON EL SERVICIO

En nuestros tratos personales o profesionales todos nos enfrentamos a situaciones en las que recibimos o damos atencin al cliente. Algunas veces damos por sentado un buen servicio, pero raras veces olvidamos uno malo. Si sufrimos una experiencia desagradable con un empleado de la compaa, es poco probable que regresemos o continuemos realizando transacciones con esta organizacin. Aunque slo un empleado haya sido descorts e ineficiente, tendemos a recordar a la empresa completa en forma negativa. Un servicio de calidad debe proporcionarse a los clientes en cualquier oportunidad que se nos presente. Un servicio de calidad a los clientes requiere de buenas habilidades de comunicacin, cmo escuchar con atencin, preguntar minuciosa y apropiadamente, explicar con efectividad, y lograr un entendimiento y un acuerdo mutuos. Es bueno recordar que el servicio a los clientes a menudo requiere "arreglar" el estado emocional y mental del cliente, tanto como arreglar el desperfecto del aparato que nos trae o resolverle algn problema. Nuestro objetivo es dejar satisfecha la necesidad el cliente. No siempre es posible satisfacer cualquier necesidad que nos presenta un cliente, pero si utilizamos el modelo de cuatro pasos habremos hecho nuestro mejor esfuerzo. A nivel tcnico o de comunicacin y nos sentiremos orgullosos de nuestro trabajo el cliente se sentir bien, nuestra compaa gozar de buena imagen y nos ganaremos el respeto de los dems. El brindar un buen servicio beneficia a todos los involucrados.
COMO TRATAR CON CLIENTES DIFICILES

Los representantes de servicio a clientes se enfrentan casi a diario a situaciones donde los clientes se quejan y en ocasiones les provocan molestia y enojo. Tales situaciones suelen ser muy incmodas y pueden volverse an ms serias si no son resueltas a tiempo. No slo afectan el asunto que se est negociando, sino tambin la reputacin de la compaa u organizacin. COMO TRATAR CON CLIENTES DIFICILES es una tcnica que nos ensea a tratar con efectividad a los clientes molestos. Al dar los pasos apropiados, los representantes de servicio pueden resolverles sus problemas convirtiendo as clientes insatisfechos en satisfechos. El reto para el representante de servicio es mantener un trato profesional mientras trabaja en busca de una solucin. Las tcnicas bsicas de comunicacin para hacer esto se describen en la pelcula. Las situaciones presentadas en COMO TRATAR CON CLIENTES DIFICILES muestran la frustracin que se desarrolla tanto en el representante de servicio como en el cliente, cuando ste tiene una queja. Los clientes insatisfechos pueden volverse enojados, groseros y hasta amenazadores. El representante de servicio debe mantener la calma y enfocar la atencin de ambos en resolver el problema.
Pg. 171 de 200
COMO TRATAR CON CLIENTES DIFICILES muestra a tres clientes insatisfechos y las situaciones difciles que les crean a los representantes de servicio en situaciones sobre el mostrador, en el telfono y en el campo. En cada situacin el representante demuestra las actitudes y acciones apropiadas para calmar al cliente, identificar los problemas e iniciar con l rutas e trabajo para encontrar soluciones. La resolucin del problema de tratar con clientes difciles indica los cinco pasos: 1. Mantener una actitud amigable y profesional. 2. Reconocer que existe una situacin difcil. 3. Calmar al cliente por medio de preguntas y verificaciones. 4. Enfocar al cliente en el problema. 5. Manejar el problema.
METODO DE 10 PASOS PARA LA ATENCION DE UNA QUEJA

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Mantener una actitud de servicio Ser amable en todo momento, control emocional Escuchar al cliente sin interrumpir Ofrecer una disculpa y ponerse en lugar y del lado del cliente, entender que para l es un problema Repetir su queja a l mismo demostrando que se le entiende Explicarle como se le dar solucin al problema Resolver o tramitar personalmente el problema o canalizarlo a otra instancia Dar seguimiento hasta el final de la solucin del problema Dar las gracias al cliente por la oportunidad de servirle Gnese al cliente, deje condiciones para la prxima compra
7 ASPECTOS DE CONSULTOR INFORMTICO
Un Consultor de informacin tecnolgica en negocios, debe ser un aliado en cada sentido de la palabra. Superficialmente podra sonar un poco cmodo y posiblemente un poco optimista. Algunos consultores IT se pueden enfocar en cumplir sus necesidades bsicas. Ellos le proporcionarn consejos tecnolgicos y le suministrarn productos tangibles y servicios que sean necesarios para satisfacerle todas sus necesidades. Pero lo que espera usted razonablemente de su Consultor IT va ms all de eso, ellos deben corresponder a los intereses de su negocio, brindndole los beneficios y guindole ya que esto es fundamental para el crecimiento y xito de su compaa.
Aqu hay 7 aspectos que esperar de su Consultor IT: s p e c iia lli a c ii n c n iic a n a u e r 1 t e a b iil iid a d e o m u n iic a c iii n E s p e c a c n t c n a y u n a u e r t e h a b a d d e c o m u n a c n 1.. E E s p e c ia a liz iz z a c i nt t c n ic c ay yu u n a fff u e r t eh h a b ill id d a dd d ec c o m u n ic c a c n::
Por su puesto su Consultor IT debe estar bien informado de todos los avances de la tecnologa, pero esa clase de conocimiento puede tener poco valor acadmico si su Consultor IT no tiene el conocimiento de cmo aplicarlo a su negocio, por eso l debe de ser primero y por encima de todo un hombre de negocios quien utiliza la tecnologa de manera que tenga un costo efectivo para resolver los problemas de su empresa.
2 . o n o c iim iie n t o e u r e s u p u e s t o e c u r s o s 2 . C o n o c n t o d e s u p r e s u p u e s t o y r e c u r s o s : 2 . C C o n o c im m ie e n t od d es s up p r e s u p u e s t oy yr r e c u r s o s: :
Los Consultores IT est demostrado que proveen un incremento sustancial de productividad en las empresas. Pero esta clase de actividad no debe de ser cara. Cuando buscamos un Consultor IT nos preguntamos cual es la estructura de su costo y ciertamente un Consultor IT responsable no podra ser gratis, pero puede acomodarse a sus necesidades empresariales y tecnolgicas. Por ejemplo un Consultor para nivelar las habilidades de su Help desk y los servicios de la reparacin, mantenimiento, resolucin de requerimientos internos de la empresa.
Pg. 172 de 200
3 . n a o n s u llt o r a u e a r t e r a v s e r o d u c t o s llt a e c n o llo g a : 3 . U n a c o n s u o r q u e p a r t e a t r a v s d e p r o d u c t o s a a t e c n o g : 3 . U U n ac c o n s u lt t o r a aq q u ep p a r t ea at t r a v sd d ep p r o d u c t o sa a lt t at t e c n o lo o g a a :
Ningn Consultor IT puede mantenerse a flote si un negocio no atiende a sus recomendaciones, ya sea de un paquete se Software o un plan de implementacin. Pero los Consultores IT verdaderamente eficaces identificarn opciones tcnicas eficaces para sus clientes. Un Consultor IT eficaz puede cubrir la brecha entre los productos de alta tecnologa de un vendedor y la verdadera solucin comercial. l tambin debe ayudar a determinar si una empresa est acostumbrada a su tecnologa actual y mejorar esa capacidad para aumentarla al mximo con los productos que poseen.
4 . n o n s u llt o r T e b e e r lla n iii g iia s a r a u lli n t e : fff iic a d o r , p lle m e n t a d o r , e s t r a t e 4 . U n C o n s u o r T d e b e s e r p n g s p a r a s u c n t e : a d o r , p m e n t a d o r , d e e s t r a t e 4 . U U nC C o n s u lt t o r III Td d e b es s e rp p la a n g ia a sp p a r as s uc c lie ie e n t e : ic c a d o r , iim im m p le e m e n t a d o r ,d d ee e s t r a t e
Aun el ms cuidadoso plan de tecnologa si no se usa, se vuelve obsoleto. Comprometerse con un Consultor IT, significa que manejar la implementacin, ya sea a travs de una introduccin gradual que vaya cambiando la tecnologa. Esto quiere decir que se sugerir un plan de accin en base a un anlisis de la situacin actual de una empresa, conociendo los requerimientos y alcances que tiene la misma, para recomendar la tecnologa apropiada al caso. Est seguro de que su Consultor IT sabe la mejor manera de irlo guiando a travs de las recomendaciones tecnolgicas. Un Consultor IT le ayudar con la creacin del plan, l podr priorizar la menor y ms efectiva estrategia de implementacin.
n b s e r v a d o r d u s t r iia lll q u iie n o n o c e s v a n c e s e e c n o g a c o p lla s U n o b s e r v a d o r d u s t r q u n c o n o c e s a v a n c e s d e t e c n o g a y a c o p a s 5. U U no o b s e r v a d o r iin in n d u s t r ia a q u ie e nc c o n o c e llo lo o sa a v a n c e sd d e lla la at t e c n ollo lo o g ay y lla la aa a c o p la aa a lla la a s n e c e s i d a d e s d e l a e m p r e s a : n e c e s i d a d e s d e l a e m p r e s a : necesidades de la empresa:
Un Consultor IT pro activo es el que est preparado para la nueva tecnologa que usted necesita y le sugiere las actualizaciones y los cambios de acuerdo a sta. Esto significa llevar a cabo un crecimiento y desarrollo en su negocio as como un progreso en le mundo de la tecnologa aplicndola a sus necesidades. Los Consultores IT deben desarrollar continuamente implementaciones y actualizaciones y as poder ofrecerle una mejor visin estratgica de las nuevas soluciones y como la tecnologa puede reducir los costos y hacer ms dinmico el funcionamiento de la lnea de trabajo.
6 . o s e e r n a e r s p iii c a z a b iil a d m a s : e r r e g lla r e s o llv e r o s r o b 6 . P o s e e r u n a p e r s p c a z h a b a d m a s : d e a r r e g r y r e s o e r o s p r o b 6 . P P o s e e ru u n ap p e r s p c a zh h a b ili lid id d a dd m a s : d ea a r r e g la a ry yr r e s o lv v e r lll o sp p r o blle le e
Es poco realista pensar que cualquier elemento de tecnologa no importa que tan caro o sofisticado sea es totalmente inmune a daos. Un Consultor IT debe estar siempre preparado a resolver estos problemas rpidamente, l debe de ir un paso ms all vigilando el mantenimiento regular de todas las actualizaciones del plan de trabajo y los recursos que este involucra, para que se puedan contemplar contingencias a cada posible situacin que se presente. Ellos deben de proporcionar una solucin rpida a una emergencia y que sta sea rentable cuando no podamos evitar el problema. Ellos deben de proporcionar el mantenimiento de las redes y todos los sistemas conectados a stas, polticas de seguridad, Back Ups y todos los sistemas de proteccin contra virus para que estos problemas puedan prevenirse.
7 . o s e e r n t e r s n a n e jjj a r : o d a s u s e c e s iid a d e s e c n o ll g iic a s 7 . P o s e e r u n t e r s e n m a n e a r : t o d a s s u s n e c e s a d e s t e c n o g a s 7 . P P o s e e ru u n iin in n t e r se e nm m a n e a rt t : o d a ss s u sn n e c e s id d a d e st t e c n o l g ic c a s
Nada puede ser ms molesto que malgastar tiempo y dinero en consultores o en negocios individuales para suplir sus necesidades tecnolgicas. Un elemento final al adquirir un Consultor IT es saber que toda la tecnologa que usted necesita se reunir bajo un mismo techo no importando si usted se involucr como una nueva infraestructura de negocios o un usuario bsico. Ellos deben de actuar como un solo punto de responsabilidad y suplirle de toda la tecnologa necesaria para su empresa.
CONCEPTO DE PETI PLANEACIN ESTRATGICA DE TI

La PETI (Planeacin Estratgica de Tecnologas de Informacin) es ampliamente reconocida como una herramienta para ordenar los esfuerzos de incorporacin de TI. Dicha herramienta establece las polticas requeridas para controlar la adquisicin, el uso y la administracin de los recursos de TI. Integra la perspectiva de negocios y organizacional con el enfoque de TI. Estableciendo un desarrollo informtico que responde a las necesidades de la organizacin y contribuye al xito de la empresa. Su desarrollo esta relacionado con la creacin de una plan de transformacin, que va del estado actual en que se encuentra la organizacin, esto, en concordancia con la estrategia de negocios y con el propsito de crear una ventaja competitiva. La PETI consiste en proceso de planeacin en el que las estrategias sufren una continua adaptacin, innovacin y cambio, que se refleja ene los elementos funcionales que componen toda la organizacin. Trabajos relacionados con la construccin de un PETI, han sido desarrollado desde hace tres dcadas, pero presenta limitaciones importantes debido a que en casos hay procesos de RE INGENIERIA en los procesos de la organizacin, lo cual no siempre es fcil de realizar. Un proceso de planeacin de TI que integre las necesidades de la organizacin, resulta una tarea compleja, es por eso que la metodologa de PETI debe ser administrada e implementada por un consultor con habilidades tcnicas, administrativas, comunicativas y capacidad de crear vnculos entre las diversas partes de una organizacin. Es por ello que se recomienda que sea un consultor externo, ya que deber de poseer los 7 aspectos de un consultor de TI. Es por eso que este resumen de la metodologa PETI cuenta con el formalismo y la potencialidad de expresin necesaria para administrar y ejecutar esta tarea. Al mismo tiempo contribuye a establecer una clara relacin entre la Cristian Bailey Consultor IT Pg. 173 de 200
planeacin estratgica de negocios, el modelado de la organizacin y la TI (TI - Tecnologas de Informacin IT Informtica y Tecnologa IS Informacin y Sistemas SI Sistemas de Informacin). Su construccin esta basada en un modelo conceptual que propone una alternativa que se basa en la transformacin de la estrategia de negocios en componentes operativos y de TI.
TICA PROFESIONAL EN TI
El ser humano no es solo el yo individual, sino tambin es el yo social. El yo individual le permite la libertad de eleccin, el yo social le indica que su accin tiene consecuencias que trascienden la individualidad, es de esta forma que: El acto del ser humano es un acto consciente, libre y voluntario que en automtico se convierte en un acto moral, el cual nos remite a la responsabilidad, la que nos obliga a responder por lo actuado o no actuado. De esta manera, se puede responsabilizar a cualquier persona por algn hecho, ya sea por la mala aplicacin de sus conocimientos o por realizar una mala evaluacin, por ausencia, abuso de poder, mala prctica y por dar informaciones tergiversadas. Actuar ticamente implica, entonces, actuar acorde con las normas y reglas de comportamiento impuestas por la sociedad que nos rodea, por eso la tica vive en cada ser humano sea cual sea su profesin y su entorno. La tica profesional, por ende, nace de un trabajo al servicio de los dems. sta se debe vivir en cada una de las situaciones afrontadas en nuestra vida (social o laboral), permitiendo as la bsqueda de la excelencia profesional a travs de la honestidad y responsabilidad. De esta forma entiendo que la ETICA PROFESIONAL es parte de la conciencia individual, que se manifiesta en un compartimiento social responsable acerca de los deberes de una profesin, despus de haber asumido un cdigo de tica conocido o escrito, mediante un proceso de socializacin, manteniendo el equilibrio entre lo personal y social que permita estudiar, aplicar y resolver problemas profesionales con la mejor competencia y rectitud posibles. Es por esto que el compromiso como integrante de un proyecto, cualquiera que sea su ramo, es proporcionar informacin verdica y objetiva con alta calidad. Estamos inmersos en un mundo que enajena con mucha frecuencia al ser humano, lo masifica, opacando su individualidad, en un mundo que, a pesar de haber alcanzado un alto nivel tecnolgico, incluida la informacin cotidiana de lo que ocurre en cualquier latitud, deja de lado los derechos individuales; es un mundo donde el lema es la competitividad y la bsqueda del triunfo individual, sin importar los medios para lograrlo. Por eso, no est de ms hablar de la importancia de la responsabilidad y honestidad que deben tener todas las personas, especialmente las profesionales, que con su conocimiento tienen mayor acceso al poder y, por lo tanto, mayor responsabilidad, porque a mayor conocimiento mayor responsabilidad. A cada individuo le corresponde ser protagonista importante del mundo actual, y de stos se requiere una sensibilidad de conciencia profesional y de apego a la verdad, a la honestidad y a la responsabilidad, porque tienen entre sus manos la tarea enorme de informar y orientar a la sociedad. Todos los profesionistas estamos para servir con ETICA PROFESIONAL en cada proyecto. Tenemos las herramientas y conocimientos necesarios para que la necesidad de nuestra sociedad encuentre en nosotros el verdadero valor de la verdad y podamos construir y dar el valor agregado que nuestro pas necesita. El fin de la tica es indicarnos el camino del bien. Y el bien, es el objeto al que dirigimos todas nuestras actividades
FRASES CELEBRES EN LA ADMINISTRACIN DE PROYECTOS:

"El requisito del xito es la prontitud en las decisiones" Cristian Bailey Consultor IT Pg. 174 de 200
- Francis Bacon "Son lderes quienes, por medio de una comunicacin eficaz, influyen a otros a seguirlos" - Barry Bowater "El maestro mediocre, dice. El buen maestro, explica. El maestro superior, demuestra. El gran maestro, inspira" - William Arthur Ward "Son dos las opciones bsicas: aceptar las condiciones como existen o aceptar la responsabilidad de modificarlas" - Denis Waitley "Liderazgo significa que un grupo, grande o pequeo, est dispuesto a confiar la autoridad a una persona que ha demostrado capacidad, sabidura y competencia" - Walt Disney "No basta saber, se debe tambin aplicar. No es suficiente querer, se debe tambin hacer" - Johann Wolfgang Goethe "El espritu de grupo es lo que da a muchas empresas una ventaja sobre sus competidores" - George L. Clements "El talento gana juegos, pero el trabajo en equipo y la inteligencia ganan campeonatos - Michael Jordan "La perseverancia es invencible. Por ello, el tiempo, en su accin, destruye y derriba toda potencia" - Plutarco Uno de los secretos del xito empresarial consiste no en hacer uno mismo el trabajo, sino en reconocer al hombre apropiado para hacerlo" - Andrew Carnegie El liderazgo es una tarea, no un puesto. Las personas no te pertenecen, t les perteneces a ellas" - Max De Pree
Cristaliza tus metas. Elabora un plan para alcanzarlas. Fjate una fecha lmite. Entonces, con suprema confianza, lleva adelante tu proyecto" - Paul J. Meyer La nica diferencia entre un sueo y un objetivo es una fecha - Edmundo Hoffens El Hombre planea... Dios se re - Annimo Nada sucede hasta que algo se mueve - Albert Einstein "No es el plan lo que importa, sino la planificacin" - Dr. Graeme Edwards "No me arrepiento en absoluto de haber corrido todos los riesgos por aquello que me importaba" - Arthur Miller "El ejemplo tiene ms seguidores que la razn. De manera inconsciente imitamos a aquellos que apreciamos y nos acercamos a la gente que admiramos" Cristian Bailey Consultor IT Pg. 175 de 200 MANUAL TCNICO PMI - IT
- Christian Nevell Bovee "Los grandes hombres casi nunca son cimas de montaas aisladas, son las cumbres en cordilleras gigantes" - Thomas Wentworth "El que quiera hacer todo solo, jams ser un gran lder; tampoco el que quiera quedarse con todo el crdito por hacerlo" - Andrew Carnegie "No intento bailar mejor que nadie. Slo trato de bailar mejor que yo mismo" - Mikhail Baryshnikov "Ganar no lo es todo, pero querer ganar s lo es" - Vince Lombardi "No perdamos de vista los factores ms importantes que llevan un liderazgo exitoso: el compromiso, una pasin por dejar huellas, una visin por lograr un cambio positivo y el coraje para la accin" - Larraine Matusak "El lder que ve claro ilumina a los dems" - El Tao de los lderes "Ayuda a los dems a convertirse en personas motivadas guindolos a la fuente de su propia energa" - Paul G. Thomas "El verdadero liderazgo debe ser para el beneficio de los que siguen, no para el enriquecimiento de los lderes" - Robert Townsend "Somos creadores y podemos fabricar hoy el mundo en el que viviremos maana" - Robert Collier "Son muchas las manos y los corazones que contribuyen al xito de una persona" - Walt Disney Cuando llegas a comprender cabalmente la raz del significado de la palabra "xito", descubres que quiere decir "sigue adelante" - Francis Nichol "Un gran lder es el que puede ayudar a otros a descubrir su potencial por s mismos" - Bo Bennett "La tarea de un lder es llevar a su gente de donde est, hasta donde no haya llegado jams " - Henry Kissinger "El liderazgo es el uso inteligente del poder, el poder es la capacidad de traducir intencin en realidad y sostenerla" - Warren Bennis "La magnitud de un lder est dada por la profundidad de sus convicciones, el grado de sus ambiciones, el ngulo de su visin y el alcance de su amor" - D.N. Jackson" "Un lder es alguien a quien sigues a un lugar al que no iras por ti mismo" - Joel A. Barker "El verdadero liderazgo resplandece en los tiempos de crisis" - Annimo
Pg. 176 de 200
"Un lder tiene visin y conviccin de que un sueo puede alcanzarse. Inspira el poder y la energa para que el trabajo se concrete" - Ralph Lauren "El verdadero lder siempre va un paso ms adelante que su equipo, sin embargo no lo deja atrs, lo gua para crear ms lderes. l saca lo mejor de los dems" - Jos Augusto "El lder tiene como misin primordial mejorar su propia vida, no se puede transmitir al resto lo que no se posee con anterioridad" - Fernando Grosso "Los lderes que prometen sangre, sudor y lgrimas siempre consiguen ms de sus seguidores que aquellos que les prometen seguridad y buenos momentos" - George Orwell "En lugar de ser un hombre exitoso, busca ser un hombre valioso: lo dems llegar naturalmente" - Albert Einstein "Si el lder no sabe cmo hacer que su visin se concrete, es slo un soador" - Annimo "El mejor lder es el que apenas se hace notar, Y... cuando ha concluido su trabajo y alcanzado su propsito, la gente dir: lo hicimos nosotros" - Charles C. Manz y Henry P. Sims Jr "Arriesgarse a quedar como un tonto, ese es el primer paso hacia la sabidura" - James G. Huneker "Si no lo puedes planear, menos an lo vas a poder realizar" - Annimo "Se puede definir al liderazgo como una cierta capacidad de transformar una visin en realidad" - Warren Bennis "El hombre que con certeza avanzar es aquel demasiado grande para su lugar" - Wallace D. Wattles
"No se trata de una personalidad magntica, eso puede ser slo facilidad de palabra. Tampoco de hacer amigos o influir sobre las personas, eso es adulacin. El liderazgo es lograr que las miradas apunten ms alto, que la actuacin de la gente alcance el estndar de su potencial y que la construccin de personalidades supere sus limitaciones personales" - Peter Drucker "En pocas palabras, un lder es un hombre que sabe adnde quiere ir, se pone de pie y va" - John Erskine MANUAL TCNICO PMI - IT Pg. 177 de 200 "Cuando el trabajo de un gran lder concluye, la gente dice: Lo hicimos!" - Lao Ts "No estamos interesados en la posibilidad de la derrota" - Reina Victoria de Inglaterra "Todos los hombres de accin han sido y son tambin soadores" - James E. Huneker
"La primera y la mejor de las victorias es la conquista de uno mismo" - Platn "Los lderes no infligen dolor, lo soportan" - Max De Pree "El secreto del triunfo empresarial es conectar con el corazn de las personas. El verdadero liderazgo de los seres humanos consiste en felicitarlos y no en condenarlos" - Robin S. Sharma Sabes y actuar son uno mismo Maestro Zen El ancestro de toda accin es un pensamiento -Annimo. Las palabras son sustentadas por las acciones - Cristian Bailey Cuando las rdenes son razonables, justas, sencillas, claras y consecuentes, existe una satisfaccin recproca entre el lder y el grupo. -Sun tzu
CONCLUSIONES.
El administrar un proyecto de TI es complejo, requiere de un comit, gerentes de proyecto, y personal tcnico y administrativo que trabaje en el mismo, pero mas que nada se debe tener en cuenta que es un proyecto de EMPRESA y no de TI, esto significa que el apoyo de la empresa y sus directivos es primordial para que sea exitoso. Trabajo en equipo multidisciplinarlo y multiempresarial es el termino correcto, con una sistemtica coordinacin.
RECOMENDACIONES.
Que las personas que sern responsables de este tipo de actividades reciban capacitacin del PM BOOK, ITIL, COBIT, RUP, MSF para que tengan conocimientos slidos de todo lo que implica este tipo de Gestin.
Pg. 178 de 200
GLOSARIO.
Actividad: Son las diferentes acciones que se desarrolla a lo largo de un proyecto. esta tiene una durabilidad, un costo, y asignacin de recursos. Se dividen en tareas. Actividad crtica: Cualquier actividad sobre la ruta crtica, se determina usando el mtodo de la ruta crtica. Aunque algunas actividades son "crticas" en el sentido del diccionario sin estar sobre la ruta crtica, este sentido pocas veces se usa en el contexto del proyecto. Actuales o presentes (Actuals): Es el costo o esfuerzo incurrido al realizar tareas. Tambin son las fechas en las que se han empezado o terminado tareas en las que se han alcanzado logros significativos. AdministracindelAlcancedelProyecto: Es parte de la administracin de proyectos que incluye los procesos necesarios para asegurar que el proyecto incluya todo el trabajo requerido para terminar el proyecto de manera exitosa, y consiste de iniciacin, planeacin del alcance, definicin del alcance, verificacin del alcance, y control de cambios al alcance. Administracin de Calidad del Proyecto: Es la actividad derivada de la administracin de proyectos, donde se realizan los procesos necesarios para llevar a cabo el proceso de manera satisfactoria, es decir que cumpla con los objetivos para los que fue creado. Consiste llevar a cabo un control de calidad eficiente y efectivo. Administracin de la Comunicacin del Proyecto: Parte de la administracin de proyectos que incluye los procesos requeridos para asegurar la adecuada diseminacin de la informacin en el proyecto. Esta consiste de planeacin de las comunicaciones, distribucin de la informacin, reportes de desempeo etc. AdministracindelaIntegracindelProyecto: es una parte de la administracin de proyectos que incluye los procesos requeridos para asegurar que los elementos varios del proyecto estn adecuadamente coordinados. Y consiste de desarrollo del plan del proyecto, ejecucin del plan de proyecto, y control de cambios general. Administracin de Portafolio: Consiste en la direccin concentrada de uno o ms portafolios, que incluye la identificacin, priorizacin, autorizacin, gestin y control de proyecto, programas y otros trabajados relacionados, de tal manera que stos apunten al logro de las metas estratgicas de negocio de una organizacin. Administracin de Procesos de Negocio (BPM): Es la metodologa empresarial cuyo objetivo es mejorar la eficiencia a travs de la gestin sistemtica de los procesos de negocio, que se deben modelar, automatizar, integrar, monitorizar y optimizar de forma continua. Administracin de Proyectos: Es el proceso de planear, organizar, dirigir y controlar el uso de recursos para lograr objetivos, que se plantean desde un principio por los involucrados en el proyecto. Administracin de Proyectos Moderna (MPM): Trmino utilizado para distinguir a la corriente de la administracin de proyectos que se enfoca en. alcance, costo, tiempo, calidad, riesgo, etc. de la corriente tradicional que se enfoca solamente en costos y tiempo. Administrador de Proyectos Profesional (PMP): Es un individuo certificado como tal por el PMI (Project Management Institute). MANUAL TCNICO PMI - IT AdministracindelRecursoHumanodelProyecto: Es la parte de la administracin de proyectos que incluye los procesos requeridos para hacer el uso ms efectivo de las personas involucradas en el proyecto. Esto consiste de planeacin organizacional, adquisicin de staff, y desarrollo del equipo. Administracin de Riesgo del Proyecto:Es una parte de la administracin de proyectos que se encarga de identificar, analizar, y reaccionar al riesgo del proyecto. Consiste en la identificacin de riesgo, cuantificacin y valoracin del riesgo, respuesta al riesgo, y control de respuesta al riesgo.
Pg. 179 de 200
Administracin del Tiempo del Proyecto: Actividades de la administracin de proyectos que incluye los procesos que se requieren para la oportuna terminacin del proyecto. Y consiste de definicin de actividades, secuencia de actividades, estimacin de duracin de actividades, desarrollo de la programacin, y control de la programacin. Administracin de Valor Devengado (EVM): Tcnica usada para integrar el alcance, calendario y recursos de un proyecto y medir y reportar su desempeo desde el inicio hasta el final. Administracin Total de Calidad (TQM): Una aproximacin comn para implementar un programa de mejoramiento de la calidad dentro de una organizacin. Administracin de Costos del Proyecto: Es la actividad derivada de la administracin de proyectos, donde se realizan los proceso necesarios para llevar a cabo el proceso dentro del presupuesto contemplado para el. Esta consiste de planeacin de recursos, estimacin de costos, presupuestacin de costos, y control de costos. Adquirirelequipodelproyecto: Es un proceso que consiste en aprobar a las personas que estn disponibles e integrar el equipo que se encargar de realizar las actividades del proyecto. Alcance: Es el trabajo que tiene que ser hecho para entregar los resultados planteados. Se refiere a los requerimientos a satisfacer en el proyecto. Amenaza: Una caracterstica o evento desfavorable para el proyecto. Cmulo de situaciones negativas, que de hacerse realidad generarn un riesgo que si se hace realidad tendr un impacto adverso dentro del proyecto. Anlisis Monte Carlo: Es una tcnica que se basa en el clculo o repeticin del costo o del cronograma del proyecto, a travs del uso de valores de datos iniciales seleccionados de manera aleatoria partiendo de de distribuciones de probabilidades de costos o duraciones posibles. Anlisis de Negocio: Se refiere a un conjunto de tareas y tcnicas que son requeridas para determinar las necesidades del negocio y establecer las soluciones a los problemas del mismo. Anlisis de Red. Proceso de identificar las fechas tempranas y tardas de comienzo y terminacin para las actividades de un proyecto. Vase tambin Mtodo de la Ruta Crtica, evaluacin grfica. Aseguramiento de Calidad: Es el proceso sistemtico de revisin de un procedimiento, producto o sistema apoyado por normas o estndares que establecen los niveles de eficacia. Autoridad: Es la habilidad de lograr que la dems gente acte en base a tus decisiones. La autoridad se basa generalmente en la percepcin de que una persona ha sido oficialmente autorizado para emitir ordenes(obligatorias).
B
Benchmarking: Consiste en hacer una revisin de los que otros estn haciendo para establecer una comparacin con aquellos que son ms destacados o demuestran mayor xito dentro de un rea especifica, convirtindose en puntos de referencias para acciones comparativas y con base a stas emularlos o superarlos. Business Intelligence. Inteligencia de Negocio (BI) es una categora de aplicaciones y tecnologas para obtener, almacenar, analizar y proveer acceso a datos que ayuden a los usuarios a tomar mejores decisiones de negocios. Las aplicaciones de inteligencia de Negocio incluyen actividades como sistema de soporte a decisiones, consulta y reportes, proceso analtico en lnea, anlisis estadstico, proyecciones y minera de datos.
Pg. 180 de 200
Cadena de valor: Concepto desarrollado por Michael Porter donde establece una forma para clasificar los procesos de una compaa en dos grupos: unos primarios y unos de soporte. En el grupo de procesos primarios se encuentran los procesos de logstica hacia adentro, operaciones, logstica hacia afuera, mercadeo, y servicio postventa. En el grupo de procesos de soporte se encuentran procesos de administracin, gestin de tecnologa, gestin del recurso humano y gestin de compras y adquisiciones. El valor se agrega en la medida en que cada proceso se hace ms productivo. Calidad: Propiedad o conjunto de propiedades inherentes a algo, que permiten juzgar su valor al ser comparadas con otras de la misma especie. La calidad es subjetiva al cliente segn las normas ISO. Cambio: Diferencia en un valor o un acontecimiento previsto. Los cambios ms significativos de la gerencia de proyecto se relacionan con la definicin del alcance, la disponibilidad de recursos, el horario y el presupuesto. Caso de negocio (Business Case): La informacin que describe la justificacin para el proyecto. Se justifica el proyecto si los beneficios previstos compensan los costos y riesgos estimados. El caso del negocio es a menudo complejo y puede requerir anlisis financiero, anlisis tcnico, anlisis del impacto de la organizacin y un estudio de viabilidad. Casodeprueba: Es un escenario concreto en un ambiente conocido, que se puede llevar a cabo de principio a fin, con un grupo de entradas, pasos y salidas precisamente identificados. Causaespecial: Una fuente de variacin que no es inherente al sistema, que no es previsible y que es intermitente. Charter: es el documento que autoriza de manera formal la realizacin de un proyecto otorgando a las personas involucradas la responsabilidad y la autoridad que necesitas. En el se incluyen las expectativas del proyecto, el alcance, los recursos etc. CiclodeVidadelProyecto: Es la sucesin de etapas o fases que componen proyecto Cierre administrativo: Consiste en generar, recoger, y diseminar la informacin del proyecto para formalizar la terminacin de este. Cliente: persona u organizacin que es el principal beneficiario del proyecto. Generalmente el cliente tiene una autoridad significativa con respecto a la definicin del alcance y si el proyecto debe ser iniciado y/o continuado. Compensacin: Es algo que es dado o percibido, puede ser un pago o un estmulo, usualmente est representado monetariamente o en especie por productos, servicios o resultados suministrados. Compresin de Duracin: Acortar la programacin del proyecto sin reducir el alcance del proyecto. La compresin de duracin no siempre es posible y muchas veces requiere un incremento en el costo del proyecto. Contrato: Es un convenio o acuerdo obligatorio para las partes involucradas, por el cual un vendedor se compromete a proveer un bien, servicio o determinado resultado y un comprador a pagar por ste. Control: Es la etapa de la administracin encargada de evaluar el desempeo real y compararlo con el plan estratgico planteado. MANUAL TCNICO PMI - IT Control de Calidad (QC): (1) es el conjunto de acciones correspondientes al monitoreo de actividades y resultados con el fin de determinar si estas estn siendo cumplidas en base a los estndares de calidad establecidas, eliminar procedimientos que no cumplan con los estndares y crear nuevas tcnicas para lograr los objetivos deseados. (2) Es el departamento dentro de la organizacin encargado del control d calidad de las operaciones de la empresa. Control de cambio: Consiste en hacer la identificacin, documentacin, aprobacin o rechazo, as como la inspeccin de las modificaciones en las lneas base de un proyecto. Cristian Bailey Consultor IT Pg. 181 de 200
Corrupcin de Alcance (Scope Creep): Consiste en agregar nuevos elementos o funciones, lo que provoca el incremento del alcance del proyecto, sin tener en cuenta los efectos que esto pueda tener sobre el tiempo, costos y recursos, o sin la aprobacin del cliente. Costo: Es el monto en dinero o valor de una actividad o elemento del proyecto que incluye el precio de los recursos requeridos para ejecutar y concluir la actividad o el elemento, o para generar un componente. Costos de la Calidad: Son todos los costos en que se incurre para asegurar la Calidad de un proyecto. Esto implica la planeacin de la calidad, aseguranza de la calidad, y rehacer trabajo. Costeo de Ciclo de Vida: Concepto de incluir los costos de adquisicin, operacin, y eliminacin cuando se evalan varias alternativas. Costos de la Calidad. Costos en los que se incurre para asegurar la calidad. El costo de la calidad incluye la planeacin de la calidad, aseguracin de la calidad, y rehacer trabajo. Costo Presupuestado del Trabajo Realizado (BCWP): Suma de los estimados presupuestales aprobados (incluyendo cualquier provisin para los costos administrativos) para actividades (o porciones de actividades) programadas para ser ejecutadas durante un periodo dado (usualmente el proyecto-hastala fecha). CostoRealdeTrabajoRealizado(ACWP):Costos en los que se incurre al realizar trabajos en un periodo dado. Crashing: Tcnica que permite reducir la duracin total del proyecto despus de analizar un nmero de alternativas para determinar como conseguir la mxima reduccin de la duracin por el mnimo costo. Cronogramadelproyecto: Son las fechas que han sido planificadas para llevar a cabo las actividades y cumplir con los hitos. Cuantificacinderiesgo: Consiste en evaluar la probabilidad de la ocurrencia de eventos de riesgo y sus efectos. Cuerpo de Conocimientos de la Administracin de Proyectos (PM BOOK): Es un trmino inclusivo que describe la suma de conocimientos dentro de la profesin de la administracin de proyectos. El PMBOK incluye prcticas tradicionales probadas que son de uso generalizado, as como prcticas innovadoras y avanzadas que han visto un uso ms limitado. CurvaS: Muestra grfica de acumulados de costos, horas hombre, u otras cantidades, graficadas contra tiempo. El nombre se deriva de forma de "S" de la curva producida en un proyecto que comienza lentamente, se acelera, y luego decae.
Defecto: Algn desperfecto o insuficiencia en un elemento de un proyecto, generando que este componente no cubra las exigencias o detalles y tenga que ser arreglado o sustituido. Delphi: Es una tcnica para recolectar informacin que se usar como procedimiento para alcanzar el convenio de expertos en un tema. Desarrollo del Plan de Proyecto: Es tomar los resultados de los otros procesos de planeacin y colocarlos un solo documento consistente y coherente. Desarrollo de la Programacin: Anlisis de la secuencia de actividades, duracin de actividades, y los requerimientos de recursos para crear la programacin del proyecto. Desarrollo de Equipo: El desarrollo de las habilidades de grupo o individuales para el mejoramiento del desempeo del proyecto. Descripcin de Actividad (DA): Frase breve que se usa en un diagrama de red de proyecto. La descripcin de actividad describe tambin el alcance de la actividad. Cristian Bailey Consultor IT Pg. 182 de 200 MANUAL TCNICO PMI - IT
Desarrolloencascada: Es un enfoque metodolgico caracterizado por ordenar de manera rigurosa las etapas del ciclo de vida del software, en donde el comienzo de cada etapa debe esperar a la finalizacin de la inmediatamente anterior. Diagrama de control: Es una forma grfica de representar datos del proceso en un periodo determinado comparndolo con trminos de control establecidos. Este tipo de imgenes poseen una lnea central que permite detectar una propensin de lo valores trazados contra cualquiera de los trminos de control. DiagramadeGantt: Es una matriz de doble entrada en la cual se anotan en las filas, las distintas actividades que componen un programa o proyecto, mientras que en las columnas se coloca el tiempo en el cual se desarrollarn las tareas. Es una herramienta til para idetificar fcilmente las actividades y los tiempos de duracin de stas dentro de un proyecto, lo que permite visualizar cmo debe ir avanzando ste. DiagramadePareto: Histograma, ordenado por frecuencia de ocurrencia, que muestra cuantos resultados fueron generados por cada causa identificable. Hanger. Discontinuidad o quiebre no intencionado en la ruta de la red .Los hangers generalmente son causados por actividades faltantes o por relaciones lgicas faltantes. DiagramadeReddelCronogramadelProyecto: Es la representacin en forma de esquema de las relaciones lgicas que hay entre las actividades que aparecen en el cronograma del proyecto. Diagrama de red del proyecto: Cualquier representacin esquemtica de las relaciones lgicas de las actividades del proyecto. Siempre se dibuja de izquierda a derecha para reflejar de manera correcta la cronologa del proyecto. Muchas veces se le conoce de forma inapropiada como "grfica PERT". Director del proyecto: La persona designada por la organizacin ejecutante para conducir y alcanzar los objetivos del proyecto. Documentos de adquisiciones: Son aquellos usados en las actividades de ofrecimiento y propuesta. Estos documentos son los siguientes: Invitacin a licitacin del comprador; Invitacin a negociar; Solicitud de informacin; Solicitud de Presupuesto; Solicitud de propuesta y respuestas del vendedor. Duracin (DU): Es el tiempo de trabajo (sin incluir das festivos u otros periodos de no trabajo) que se requieren para completar una actividad u otro elemento del proyecto. Se expresa generalmente das, semanas, meses etc. DuracinRemanente(RDU): Tiempo que se necesita para terminar una actividad. Ejecucin del Plan de Proyecto. Llevar a cabo el plan del proyecto al ejecutar las actividades incluidas en el.
E
Encargado funcional: Responsable de las actividades de una unidad organizacional que proporciona los productos, servicios o personal especializados a los proyectos. Por ejemplo, el encargado de un departamento de prueba o de un departamento del desarrollo de los procedimientos. Entrada: Cualquier parte, interna o externa, del proyecto que sea necesitada por un proceso antes de que ste pueda continuar. La entrada tambin puede tratarse de un proceso antecesor. Entregable:Cualquier cosa o documento producido como el resultado de un proyecto o cualquier parte de un proyecto. El proyecto entregable se distingue de los entregables parciales que resultan de actividades dentro del proyecto. Un entregable debe ser tangible y comprobable. Cada elemento del WBS debe tener unos o ms. Equipo de Direccin del Proyecto: Los integrantes de la agrupacin del proyecto quienes participan directamente en las actividades de direccin del mismo. MANUAL TCNICO PMI - IT
Pg. 183 de 200
Equipo virtual: Los miembros de un grupo quienes tienen un objetivo en comn y cada integrante cumple la labor que le corresponde, utilizando prcticamente nada de tiempo para juntas cara a cara. No obstante, para establecer el vital proceso de comunicacin se valen de herramientas tecnolgicas. Esfuerzo: Es el nmero de unidades de trabajo requeridas para completar una actividad u otro elemento de proyecto. Usualmente se expresa en horas de staff u horas hombre, das de staff, o semanas de staff. No se debe confundir con duracin. Estndar: Enfoque requerido para conducir una tarea o actividad en un proyecto. Muchas veces un estndar es una mejor prctica que debe ser seguida para una mayor oportunidad de xito. Es una especificacin que regula la realizacin de ciertos procesos o la fabricacin de componentes para garantizar la interoperabilidad. Estimacin: Es el resultado probable calculado, que regularmente se aplica a cuestiones cuantitativas como costos y lapsos de tiempo. Es el clculo de la duracin, del esfuerzo y/o del costo requeridos para completar una tarea o un proyecto. Estimacin Paramtrica: Tcnica de estimacin que usa relaciones estadsticas entre datos histricos y otras variables para calcular un estimado. Estructura de Desglose Organizacional (OBS). Representacin de la organizacin del proyecto de tal manera que se relacionan las tareas con las unidades de la organizacin. Estructura de desglose del riesgo: Es una representacin jerrquica de los eventos inciertos, los cuales son identificados y ordenados por categora de riesgo y subcategora, reconociendo las distintas reas y causas de probables riesgos. Estructura desglosada de trabajo (WBS): Agrupamiento orientado a entregables de componentes, que organiza y define el alcance total del proyecto. El trabajo que no est considerado en el WBS se considera fuera del alcance del proyecto. Cada elemento en el WBS generalmente es asignado a un identificador nico. Este identificador puede proveer una estructura para la sumatoria jerrquica de recursos de costos. Debe de usarse para verificar el trabajo del proyecto.
F
Fases del Proyecto: Es una serie de actividades subsecuentes que generalmente son realizadas para un fin que es el objetivo principal del proyecto. Fast Tracking: Tcnica para reducir la duracin del proyecto al hacer actividades en paralelo que regularmente se haran en secuencia. Tiene que ver con la relacin lgica fin inicio, ya que recomienza una actividad sin que se haya terminado la anterior. Fecha de Comienzo. Es un punto en el tiempo asociado con el comienzo de una actividad, este puede ser planeado, programado, temprano, tardo etc. FechadeComienzoCorriente: Estimacin corriente del punto en el tiempo en el cual una actividad comenzara. Fecha de Comienzo Tarda (LS). Punto en el tiempo, en el mtodo de la ruta crtica, ms tardo posible en que una actividad puede comenzar sin causar un retraso en un la fecha de terminacin del proyecto. Fecha de Comienzo Temprana: Dentro de la ruta crtica del proyecto, es un punto en el tiempo en el que de manera temprana puede iniciar una actividad, tarea o subproyecto con base en la lgica de la red y considerando cualquier restriccin de la programacin. Las fechas de comienzo tempranas pueden cambiar en la medida que el proyecto avanza y sufre o se realizan cambios al plan del proyecto. Fecha de Terminacin: Punto en el tiempo asociado con la terminacin de una actividad. Puede ser: real, planeado, programado, temprano, tardo. Cristian Bailey Consultor IT Pg. 184 de 200
FechadeTerminacinMeta(TF): Fecha en la que se planea la terminacin del trabajo de una actividad. Fecha de Terminacin Tarda (LF): Punto en el tiempo ms tardo posible en que una actividad puede ser completada sin causar un retraso en un hito especfico. Fecha de Terminacin Temprana (EF): Punto en el tiempo, en el mtodo de la ruta crtica, en el que las porciones sin terminar de una actividad se pueden terminar basadas en la lgica de la red y en cualquier restriccin de la programacin. Fiabilidad: La posibilidad de que un rubro cumpla con las caractersticas para las cuales fue ideado, en circunstancias especficas, por un lapso de tiempo determinado. Flotacin: Cantidad de tiempo que una actividad puede retrazarse desde su comienzo temprano sin atrasar la fecha de terminacin del proyecto. La flotacin puede cambiar a medida que el proyecto progresa y se efectan cambios al plan del proyecto. Tambin se le conoce como "slack". Flotacin Total (TF): Cantidad de tiempo que una actividad se puede retrasar desde su comienzo temprano sin atrasar la fecha de terminacin del proyecto. Tambin se le conoce como "slack" y flotacin de ruta.
G
Gerentedeproyecto(ProjectManager): La persona responsable y responsable de manejar el planeamiento y el funcionamiento de un proyecto. Gestionar las expectativas de los stakeholders: Es el proceso de establecer comunicacin y realizar labores junto con los interesados en el proyecto, a los de satisfacer los requerimientos que stos tengan y afrontar eventualidades que se vayan presentando. Grado: Categora asignada a productos o servicios que tienen la misma funcionalidad, pero diferentes caractersticas tcnicas. Green Project Management: No es ms que la aplicacin de acciones a favor del medio ambiente pero implementadas en todo lo que tiene que ver con la administracin de proyectos. Grupofuncional: Una unidad de organizacin que realiza una funcin especializada del negocio (diseo, gerencia de recurso humano, etc.) y puede proporcionar el personal, productos o servicios a un proyecto. Gruposdeprocesosdelproyecto: Se refiere a los cinco grupos de procesos requeridos para cualquier proyecto que cuentan con dependencias claras, y que deben realizarse con la misma secuencia en cada proyecto, indiferentemente del rea de aplicacin o detalles especficos del ciclo de vida del proyecto aplicado. Los grupos de procesos son: iniciacin, planificacin, ejecucin, supervisin y control, y cierre.
H
Hamaca: Una actividad resumen, el conjunto de actividades relacionadas entres si que se muestran como una sola y se resumen a nivel concatenado. Una actividad hamaca puede o no tener una secuencia interna. Hard crashing: Tipo de crashing que consiste en involucrar nuevos recursos al proyecto, con el fin de reducir su duracin al mximo. Herramienta: Es una cosa tangible, como una plantilla o software, que se utiliza al momento de desempear una actividad con el objetivo de crear un producto o resultado.
Pg. 185 de 200
Histograma: El histograma es una grfica de barras que permite describir el comportamiento de un conjunto de datos en cuanto a su tendencia central, forma y dispersin. El histograma permite que de un vistazo se pueda tener una idea objetiva sobre la calidad de un producto, el desempeo de un proceso o el impacto de una accin de mejora Hitos o Milestones: Eventos significativos o de trascendencia en el proyecto, generalmente la terminacin de un entregable principal del proyecto.
I
Identificacinderiesgos: Es un procedimiento que consiste en precisar qu riesgos podran afectar el proyecto y documentar sus caractersticas. Identificar a los interesados: Es el procedimiento de determinar a todas las personas u organizaciones que estn involucradas con el proyecto y de registrar informacin importante relacionada a sus intereses, intervencin e impacto en el feliz trmino del proyecto. Informacin histrica: Son todos aquellos documentos y detalles como archivos de proyectos, registros, contratos completados y proyectos cerrados, los cuales servirn como antecedente y lecciones aprendidas al momento de realizar un nuevo proyecto. Informe de desempeo: Son documentos, papeles y presentaciones que brindan informacin Documentos y presentaciones que ofrecen informacin ordenada y sintetizada sobre el comportamiento del trabajo, cuantificaciones y clculos de la administracin del valor ganado, as como el anlisis del progreso y contexto del trabajo del proyecto. Iniciacin: Comprometer la organizacin a comenzar una fase de proyecto. Insoursing: Tendencia a atender los requerimientos de estos servicios y/o procesos con personal y recursos internos de la compaa, en oposicin con el Outsourcing. Inspeccin: Es una comprobacin que permite identificar si una tarea, elemento, resultado, bien o servicio Examen o medicin para verificar si una actividad, componente, producto, resultado o servicio obedece requisitos especficos. Iteracin: Es un conjunto de periodos de tiempo dentro de un proyecto en los cuales usted produce una versin del producto ejecutable, estable, junto con cualquier otra documentacin de soporte, instalacin de scripts o similar, necesarios para usar esta liberacin.
J
Juiciodeexpertos: Es un criterio que se otorga fundamentado en la experiencia dentro de un rea de aplicacin, rea de conocimiento, disciplina, industria, entre otras.
K
MANUAL TCNICO PMI - IT KPI (Key Performance Indicators o Indicadores Claves de Desempeo): Son mtricas financieras o no financieras, utilizadas para cuantificar objetivos que reflejan el rendimiento de una organizacin, y que generalmente se recogen en su plan estratgico.
L
Lead: Es una modificacin de una relacin lgica que permite la aceleracin de la tarea sucesora. Es tambin llamada holgadura. Pg. 186 de 200
Leccionesaprendidas: Es lo que se asimila durante un proyecto y estas enseanzas pueden ser identificadas en cualquier momento del proyecto. Para que stas queden aprendidas han de registrarse como una base de conocimiento para que pueda ser revisada y estudiada en ocasiones futuras. Ley de Pareto: Aplicada a administracin de proyectos plantea que un nmero significativamente pequeo de causas usualmente generarn la mayor cantidad de los problemas o defectos. Esto se puede sustentar bajo el famoso principio 80/20 en el cual el 80% de los problemas se debe al 20% de las causas. Lnea Base: El plan original (para un proyecto, para un paquete de trabajo, o una actividad), presentado ms o menos con los cambios autorizados. Lista de materiales: Es un cuadro o tabla correctamente documentada y clasificada bajo un sentido jerrquico de priorizacin, incluyendo los conjuntos, subconjuntos y componentes fsicos requeridos para la realizacin de un producto. Lgica de red: Es la agrupacin de dependencias de actividades del cronograma que integra un diagrama de red de cronograma del proyecto. Loop: Cuando se pasa por un mismo nodo dos veces, en una ruta de red. Los loops no se pueden analizar usando tcnicas tradicionales de anlisis de red. Los loops son permitidos en GERT.
M
Matriz de Asignacin de Responsabilidades (RAM): Estructura que relaciona la organizacin a la estructura de desglose de trabajo para ayudar a asegurar que cada elemento de trabajo del alcance del proyecto sea asignado a un elemento del equipo de proyecto. Matriz de probabilidad e impacto: Es una forma usual de establecer si un riesgo se califica bajo, intermedio o elevado a travs de la mezcla de las dos dimensiones de un riesgo: su posibilidad de que suceda y su impacto en los objetivos, si el riesgo llegase a ocurrir. Mtodo de Diagramacin de Flechas: Es una tcnica de diagramacin de redes en el que las actividades son representadas por flechas. La cola de la flecha representa el comienzo y la punta, el final de la actividad. Las actividades se conectan en puntos llamados nodos para ilustrar la secuencia en la que se espera el desarrollo de las actividades. Tambin llamado, mtodo de diagramacin de precedencias. Mtodo de la Ruta Crtica (CPM): Tcnica de anlisis de red usada para predecir la duracin del proyecto, en ella se analiza la secuencia de actividades para determinar cual de ellas tienen la menor cantidad de flotacin. Cualquier retraso en un elemento de la ruta crtica afecta la fecha de trmino planeada del proyecto, y se dice que no hay holgura en la ruta crtica. Metodologa: Es una gua que contiene procedimientos, normas, prcticas y herramientas que indicarn cmo se debe actuar para alcanzar un objetivo determinado en alguna disciplina. Mtrica: Es una medida efectuada sobre algn aspecto del sistema en desarrollo o del proceso empleado que permite, previa comparacin con unos valores (medidas) de referencia, obtener conclusiones sobre el aspecto medido con el fin de adoptar las decisiones necesarias. MiembrosdelEquipodeProyecto: Son las personas que participan activamente en un proyecto, cada uno con responsabilidades especificas y estn dirigidos de manera directa o indirecta por el administrador del proyecto. Mitigarelriesgo: Consiste en una tcnica que entra dentro de la planificacin de la respuesta a los riesgos la cual va ligada con amenazas, siempre buscando disminuir la posibilidad de que ocurra algo no deseado o en todo caso que su impacto quede por debajo de un umbral considerado como aceptable. MANUAL TCNICO PMI - IT
Pg. 187 de 200
Monitorear: Recoger datos de cumplimiento del proyecto confrontndolo con un plan, generar mediciones de desempeo y propagar la informacin sobre su comportamiento.
N
Nivelacin del recurso: Es cualquier forma de anlisis de red en las que las decisiones de programacin (fechas de comienzo y terminacin) son dirigidas por preocupaciones que se desprenden de la administracin de recursos. Nodo: Es un de los puntos de definicin de una red; un punto de cruce conectado a algunas o todas de las otras lneas de dependencia. Vase tambin mtodo de diagramacin de flechas y mtodo de diagramacin de precedencias. Norma (Standard):Es un documento que se obtiene mediante el consenso y es aprobado por un organismo reconocido; brindando reglas de comportamiento y caractersticas para la ejecucin de actividades que permitan alcanzar un nivel favorable de orden y planificacin dentro de un contexto especfico.
O
Objetivo: Un objetivo es algo que debe ser alcanzado. En la gerencia de proyecto, los objetivos son los resultados deseados del proyecto o de cualquier parte del proyecto, en trminos de entregables concretos y resultados (servicio mejorado, ms dinero, etc.). Este debe ser medible y alcanzable. OficinadeAdministracindeProyectos: Es una dependencia de la organizacin a la cual se le asignan varias responsabilidades relativas a la direccin centralizada y coordinada de aquellos proyectos que se encuentran bajo su gobierno. Oportunidad: Es toda aquella circunstancia favorable que impactar de manera positiva en los objetivos del proyecto. Organigrama: Es una forma grfica utilizada para describir la correspondencia de relacin existente entre un conjunto de individuos que trabajan juntos por alcanzar un objetivo comn. Organizacin Ejecutora: Es aquella organizacin en la que los colaboradores se encuentran directamente involucrados con el desarrollo de proyectos. Organizacin Funcional: Es aquella organizacin en la que los colaboradores estn agrupado de manera jerrquica por especialidad o departamentos (produccin, administracin, recursos humanos etc.) Organizacin Matricial: Es la organizacin donde el administrador de proyectos comparte funciones y compromisos con otros administradores para la asignacin de obligaciones y prioridades. Organizacin Proyectizada: Es la organizacin donde el administrador de proyectos tiene total control sobre el proyecto a su cargo.
P
MANUAL TCNICO PMI - IT Paquete de Trabajo: Entrega al nivel ms bajo de la estructura de desglose de trabajo. Se puede dividir en actividades. Patrocinador: Es el individuo o grupo que brinda recursos financieros, monetarios o en especie hacia el proyecto. Peticindelcambio: Es la documentacin que estableces el cambio de alcance u otros aspectos del plan. Plan del Proyecto: Es un documento oficial, destinado a guiar a los involucrados en el proyecto en la realizacin, planeacin y control del proyecto. Pg. 188 de 200
Planeacin: El proceso de establecer y de definir el alcance de un proyecto, la manera en que el proyecto ser realizado (los procedimientos y las tareas), los papeles y las responsabilidades, el tiempo y las valoraciones de costos. Planeacin de Recursos: Determinacin, con base a las necesidades del proyecto, de los recursos (personas, equipo, materiales) que son necesarios para llevar a cabo las actividades del proyecto. Plantilla: Es un documento el cual no est completo del todo, pues su objetivo es brindar a quien lo utilice una distribucin o estructura definida que sirva para recolectar, ordenar y mostrar informaciones o datos. Polmica: Es un asunto o argumento debatido, el cual genera controversia debido a que en torno a ste existen ideas y tesis opuestas. Portafolio: Es la coleccin de proyectos, programas u otros trabajos que se han juntado para facilitar la administracin eficiente de ese trabajo, con la finalidad de cumplir con los objetivos estratgicos de negocio. Presupuesto: Es la valoracin aprobada para un proyecto, un elemento de la estructura detallada de trabajo u otra actividad presente en el cronograma de trabajo. Programa: Grupo de proyectos relacionados, administrados de una forma coordinada. Los programas usualmente incluyen un elemento de actividad en ejecucin. ProgramacindelProyecto: Fechas planeadas para la ejecucin de actividades y el cumplimiento de hitos. Programacin Maestra: Programacin concatenada que identifica los principales hitos y actividades para su cumplimiento oportuno. Project Management Professional, Administrador de Proyectos Profesional (PMP). Es aquel administrador de proyectos debidamente certificado por el Project Management Institute (PMI). Proyecciones: Apreciaciones o predicciones de circunstancias y situaciones futuras para el proyecto sobre la base de la informacin y el conocimiento disponible en el momento de realizar el pronstico. Proyecto: Es un trabajo o esfuerzo que se ejecuta una sola vez y que persigue un fin especfico, y tiene como caracterstica principal producir resultados nicos como un producto o un servicio. Punto de funcin: es un mtodo utilizado en ingeniera del software para medir el tamao del software. Fue definida por Allan Albrecht, de IBM, en 1979 y pretende medir la funcionalidad entregada al usuario independientemente de la tecnologa utilizada para la construccin y explotacin del software, y tambin ser til en cualquiera de las fases de vida del software, desde el diseo inicial hasta la explotacin y mantenimiento.
R
Recopilar requisitos: Es el proceso de puntualizar y establecer las necesidades de los stakeholders para acatar con los objetivos del proyecto. Recurso: Cualquier ayuda tangible por ejemplo, una persona, una herramienta, un artculo de la fuente o una facilidad usados en el funcionamiento de un proyecto. Registroderiesgos: Es el escrito donde se depositan los resultados de los estudios cualitativos y cuantitativos de riesgos, as como la planeacin de la respuesta a stos. A travs de un documento bien detallado se plasman los riesgos identificados y una serie de datos respecto a stos con la finalidad de tenerlos presente y poder reaccionar Relaciones Lgicas: Dependencia entre dos actividades de proyecto, o entre una actividad de proyecto y un hito. Estas pueden ser. comienzocomienzo , comienzofin, fincomienzo y fin-fin.
Pg. 189 de 200
Reparacin de defectos: Descripcin debidamente documentada de un desperfecto o insuficiencia en un elemento de un proyecto, con una sugerencia de subsanar el defecto o suplantar el componente completo. Requisitos: Es la declaracin de los objetivos detallados del producto que describe las caractersticas y las funciones y los apremios del funcionamiento que se entregarn en el producto. Reserva: Provisin en el plan de proyecto para mitigar riesgo de costo y/o programacin. Muchas veces es usada con un modificador para proveer ms detalle sobre qu tipo de riesgo es el que se quiere mitigar. El significado especfico del trmino modificador vara de acuerdo con el rea de aplicacin. Restriccin: Es una restriccin o limitacin que influencia el plan del proyecto. Reunin de iniciacin: Es un tipo de junta en la cual los principales interesados y participantes del proyecto son informados de las metas y objetivos del mismo, cmo estar organizado, entre otros puntos; con la finalidad de contribuir a su planeacin, asignacin de responsabilidades, etc. Riesgo: Un suceso o circunstancia indeterminada que de llegarse a concretar, tiene una consecuencia positiva o negativa en los objetivos de un proyecto. Riesgo residual: Un suceso o circunstancia indeterminada que permanece despus de haber ejecutado las respuestas a los riesgos. Ruta Crtica: Son las actividades que determinan la terminacin temprana del proyecto en un diagrama de red de proyecto, esta ruta se modifica durante el desarrollo del proyecto, depende del trmino de las actividades, este se calcula regularmente para todo el proyecto , sin embargo puede hacerse solo para una parte del proyecto. RutadeRed: Es cualquier serie continua de actividades conectadas en un diagrama de red de proyecto.
S
Salida: Se refiere a un producto, efecto, consecuencia, resultado o servicio creado por un proceso. Incluso nicamente puede tratarse de un dato Puede ser un dato primario que lleve a proceso posterior. Simulacin: Consiste en simular o aparentar la realizacin de un proyecto a travs de un modelo que traslada las dudas e inseguridades especificadas de forma detallada a su impacto en los probables objetivos del proyecto. Estos simulacros generalmente se fundamentan en modelos informticos y de estimaciones de riesgos. Sistemadeinformacindelagerenciadeproyecto(PMIS): Conjunto de herramientas y las tcnicas usadas para recolectar, integrar, y diseminar (difundir) los productos de los procesos de la gerencia de proyecto. Se utiliza para apoyar todos los aspectos del proyecto desde el inicio hasta el cierre. y puede incluir ambos sistemas, manual y automatizado. Slack: Trmino usado en PERT para flotacin. Soft crashing: Tipo de crashing que se realiza dedicando horas extras del quipo de trabajo al proyecto, con el fin de reducir su duracin total. MANUAL TCNICO PMI - IT Software de Administracin de Proyectos: Son las aplicaciones informticas destinadas y diseadas para auxiliar a la administracin de proyectos, en la planeacin, control etc., de un proyecto. SolicituddeCotizacin(RFQ): Generalmente, este trmino es equivalente a solicitud de propuesta, sin embargo, en algunas reas de aplicacin puede tener un significado ms estrecho o especfico. Stakeholder: Trmino utilizado por primera vez por R. E. Freeman, para referirse a quienes pueden afectar o son afectados por las actividades de una empresa. Estos grupos o individuos son los interesados ("stakeholders"), que segn Freeman deben ser considerados como un elemento esencial en la planeacin estratgica de negocios. Cristian Bailey Consultor IT Pg. 190 de 200
Subproyecto: Es una parte ms reducida del proyecto general, la cual se genera al fragmentar un proyecto en componentes ms fciles de administrar. Supuestos: Son elementos que para las intenciones de planificacin se toman como verdaderos, sin necesidad de que exista una prueba o demostracin
T
Tarea: Actividad del proyecto que requiere un esfuerzo, recursos y genera un entregable. Se dice que el proyecto en s, es una tarea muy grande ya que la tarea puede ser de cualquier tamao. Se utiliza tambin para denotar un fragmento de un trabajo particular en la jerarqua de la estructura WBS. TcnicadeRevisinyEvaluacinGrfica(GERT): Es una tcnica de anlisis de red que permite el tratamiento condicional y probabilstico de las relaciones lgicas (ej. algunas actividades pueden no ejecutarse). Tcnica de Revisin y Evaluacin de Programas (PERT): Tipo especfico de diagrama de red de proyecto llamado diagrama PERT, consiste en un anlisis de red orientada hacia eventos usada para estimar la duracin de un proyecto cuando existe un grado de incertidumbre elevado dentro de los estimados individuales de las duraciones de las actividades. Emplea el mtodo de la ruta crtica a un estimado de duracin. Teletrabajo: Es una forma de trabajo en la que ste se realiza en un lugar alejado de las oficinas centrales o de las instalaciones de produccin, mediante la utilizacin de las nuevas tecnologas de la comunicacin. Tolerancia al riesgo: Es el nivel, proporcin o medida de una circunstancia indeterminada que puede soportar un individuo o una empresa. Tormenta de ideas: Es una tcnica que pone en juego la creatividad de quienes la emplean y consiste en recolectar datos a travs de la generacin de ideas y puntos de vistas por parte de los miembros de un equipo o experimentados en determinado tema con el objetivo de aumentar las probabilidades de innovacin y originalidad en cuanto a una temtica. Transferirriesgo: Consiste en una tcnica de planificacin de la respuesta a los riesgos, con la cual se trasmite el impacto de una amenaza a un tercero, junto con la responsabilidad de la respuesta. Triple Restriccin: Es un marco que se utiliza para evaluar demandas contrapuestas. Este concepto suele representarse como un tringulo en el cual uno de los lados, o de los vrtices, refleja uno de los parmetros que administra el equipo de proyecto.
V
Validacin: Es la tcnica utilizada para evaluar un componente o producto durante una fase o proyecto, o incluso al concluir los mismos, con el propsito de asegurar que cumpla con los requisitos previstos. Valor Devengado: Compara la cantidad de trabajo planeada con la cantidad realmente realizada para determinar si el desempeo de costos y programacin es el planeado. MANUAL TCNICO PMI - IT Valor planificado: El importe autorizado asignado al trabajo planificado que debe ejecutarse en cuanto a una actividad del cronograma o componente de la estructura de desglose del trabajo. Variacin: Es una desviacin, modificacin o diferencia cuantificable de una referencia conocida o valor previsto. Verificacin: Consiste en la tcnica de examinar un elemento o producto al final de una fase o de todo el proyecto, a los fines de garantizar o corroborar que cumple con las condiciones y caractersticas impuestas. Cristian Bailey Consultor IT Pg. 191 de 200
Verificacin del alcance: Proceso para asegurarse de que todos los entregables del proyecto se terminarn satisfactoriamente. Esta relacionado directamente con la aceptacin de los resultados del proyecto por el cliente.
W
Workaround: Es una respuesta a un evento negativo de riesgo. Se debe distinguir de plan de contingencia. Un workaround no es planeado con anticipacin a la ocurrencia del evento de riesgo.
Pg. 192 de 200
BIBLIOGRAFAS CONSULTADAS.
- http://www.ati.es/article.php3?id_article=294 - http://ar.groups.yahoo.com/group/foro-itil/ - Manuales de introduccin a la implementacin de ITIL. - PDFs de Internet. - La direccin de proyectos en las organizaciones. J. Davidson Frame. Editorial Granica. 1999, - Material de la Ctedra de Administracin de los Recursos de la Informacin. Facultad de Ciencias Econmicas Universidad Nacional de La Plata Comit de Standards PMI William R. Duncan, Director de Standards Project Management Institute Four Campus Boulevard Newton Square, PA 19073-3299 USA
Pg. 193 de 200
NDICE
INTRODUCCIN: ...........................................................................................................................................2 CAPITULO 1 ................................................................................................................................................3 LA ADMINISTRACIN DE PROYECTOS. ..................................................................................................3 MARCO DE REFERENCIA: .............................................................................................................................3 MARCO DE REFERENCIA: .............................................................................................................................4 COMPRENDER EL PROCESO DE DIRIGIR PROYECTOS. ...............................................................................4 QU ES UN PROYECTO? .............................................................................................................................4 QU ES EL MANAGEMENT DE PROYECTO? ...............................................................................................5 EL CICLO DE VIDA DEL PROYECTO. .............................................................................................................5 DINMICA DEL CICLO DE VIDA DEL PROYECTO. .........................................................................................6 A).- SELECCIN DEL PROYECTO: ....................................................................................................................6 MTODOS DE EVALUACIN ECONMICA DE PROYECTOS:......................................................................................7 B).- PLANIFICACIN: .....................................................................................................................................7 C).- IMPLEMENTACIN: ..................................................................................................................................7 D).- CONTROL: ............................................................................................................................................8 EL CONTROL DEL PROYECTO SE DIVIDE EN DOS REAS: .......................................................................8 E).- EVALUACIN: ........................................................................................................................................8 F).- TERMINACIN: .......................................................................................................................................9 EL MANAGEMENT DE PROYECTO DE TECNOLOGA INFORMTICA Y SISTEMAS DE INFORMACIN ........10 LECCIONES CLAVES:..................................................................................................................................10 1 LECCIN: IDENTIFICAR Y EVITAR LAS TRAMPAS. ...........................................................................................10 2 LECCIN: CMO CREAR LAS ACCIONES CORRECTAS .....................................................................................11 ASPECTOS A TENER EN CUENTA PARA EL DESARROLLO DE PROYECTOS .............................................11 OPERAR DENTRO DE LAS REALIDADES DE LA VIDA ORGANIZACIONAL ..................................................11 EL DIVORCIO ENTRE LA RESPONSABILIDAD Y LA AUTORIDAD: ...............................................................11 FORTALECER LA AUTORIDAD: .......................................................................................................................11 EL AMBIENTE COMPLETO DEL PROYECTO ................................................................................................12 LA POLTICA DE LOS PROYECTOS .............................................................................................................13 TRABAJAR CON GENTE CAPAZ..................................................................................................................14 CUESTIONES GENERALES. ............................................................................................................................14 QUIN MANDA AQU? .................................................................................................................................14 EL COLABORADOR PERFECTO EN UN EQUIPO DE PROYECTO................................................................................15 LA PERSPECTIVA ORGANIZACIONAL................................................................................................................15 LA PERSPECTIVA PSICOSOCIAL. ....................................................................................................................15 TRABAJAR CON INTELIGENCIA. ......................................................................................................................15 TIPOS PSICOLGICOS. .................................................................................................................................16 CMO APLICAR A LOS PROYECTOS LA TEORA DE LOS TIPOS PSICOLGICOS. .........................................................17 EL GERENTE DE PROYECTO ......................................................................................................................17 EL ESTILO DE DIRECCIN. .........................................................................................................................17 CMO ELEGIR UN ESTILO DE MANAGEMENT. ...........................................................................................18 ESTRUCTURAR LOS EQUIPOS DEL PROYECTO Y DARLES COHESIN......................................................18 LA EFICIENCIA DEL EQUIPO. ......................................................................................................................19 Pg. 194 de 200
COMO ESTRUCTURAR LOS EQUIPOS. ........................................................................................................19 LAESTRUCTURAISOMRFICA. ...........................................................................................................19 LAESTRUCTURADELEQUIPOPORESPECIALIDAD. ...........................................................................20 LAESTRUCTURADELEQUIPOSINEGOCENTRISMO. .........................................................................20 LAESTRUCTURADELEQUIPOQUIRRGICO. .....................................................................................20 COMO CREAR LA IDENTIDAD DE UN EQUIPO. ............................................................................................21 ASEGURARSE DE QUE EL PROYECTO SE BASE SOBRE UNA NECESIDAD CLARA ...................................22 EVOLUCIN DE LAS NECESIDADES. ..........................................................................................................22 EL CICLO DE VIDA DE LAS NECESIDADES Y LOS REQUERIMIENTOS. .......................................................22 1. 2. 3. 4. APARICIN DE LAS NECESIDADES. .............................................................................................................22 RECONOCIMIENTO DE LAS NECESIDADES. .....................................................................................................22 FORMULACIN DE LAS NECESIDADES ..........................................................................................................22 REQUERIMIENTOS FUNCIONALES Y TCNICOS. ...............................................................................................23
ASPECTOS DIFCILES EN LA DEFINICIN DE LAS NECESIDADES. .............................................................23 1. CMOENCARARLASNECESIDADESNECESARIAMENTEVAGAS. ...........................................23 2. IDENTIFICARLASSOLUCIONESPREMATURAMENTE. .............................................................24 3. ENCARARLASNECESIDADESDELOSCLIENTESEQUIVOCADOS. ............................................24 ESPECIFICAR LO QUE EL PROYECTO DEBE LOGRAR. ...........................................................................25 LA NATURALEZA DE LOS REQUERIMIENTOS. ........................................................................................26 PROBLEMAS CON LOS REQUERIMIENTOS.............................................................................................26 1.REQUERIMIENTOSINCORRECTOS...................................................................................................26 2.REQUERIMIENTOSIMPRECISOSYAMBIGUOS. ...............................................................................26 3.REQUERIMIENTOSCAMBIANTES. ..................................................................................................27 LANEGOCIACINENLAESPECIFICACINDELOSREQUERIMIENTOS. ............................................28 PROBLEMASPOREXCESIVAESPECIFICACINDELOSREQUERIMIENTOS. ......................................28 PROBLEMASPOREXCESIVAFLEXIBILIDAD. .......................................................................................29 ORIENTACINGENERALPARALAESPECIFICACINDELOSREQUERIMIENTOS. ............................29 INSTRUMENTOS Y TCNICAS PARA REALIZAR EL PROYECTO..................................................................30 EL PLAN DEL PROYECTO. ......................................................................................................................30 PLANIFICACIN E INCERTIDUMBRE. ......................................................................................................30 TODO PROYECTO IMPLICA RIESGOS. ....................................................................................................30 CONTROLES DEL PROYECTO. ...............................................................................................................30 ESTRUCTURA DE ANLISIS DEL TRABAJO. ...........................................................................................31 DIAGRAMA DE GANTT. ...........................................................................................................................31 RED DE PERT / CMP. ...............................................................................................................................31 LOS INSTRUMENTOS DE PLANIFICACIN Y CONTROL: EL PRESUPUESTO. ..........................................32 COMPONENTESDELPRESUPUESTO. .............................................................................................................32 FONDODERESERVA. ..................................................................................................................................32 CONTROLDELPRESUPUESTO. .....................................................................................................................32 CURVA DE COSTES ACUMULADOS. ...........................................................................................................32 INSTRUMENTOS DE PLANIFICACIN Y CONTROL: RECURSOS HUMANOS Y MATERIALES Y SOFTWARE 33 MANUAL TCNICO PMI - IT MATRIZDERECURSOS. ...............................................................................................................................33 DIAGRAMADERECURSOSDEGANTT. ...........................................................................................................33 LAHOJADECLCULODELOSRECURSOS. ......................................................................................................33 DIAGRAMADECANTIDADDERECURSOS. .......................................................................................................33 NIVELACINDELOSRECURSOS....................................................................................................................33 CONTROLGRFICODELOSPROYECTOS. ........................................................................................................33 COMO DIRIGIR PROYECTOS COMPLEJOS Y RESOLVER PROBLEMAS ESPECIALES .................................34 LA PLANIFICACIN Y EL CONTROL DE GRANDES PROYECTOS. ...............................................................34 Cristian Bailey Consultor IT Pg. 195 de 200
LANECESIDADDEFORMALIDADENLAPLANIFICACINYELCONTROLDELOSPROYECTOSGRANDES. .....................34 LATCNICADELVALORGANADO. .................................................................................................................34 PLANIFICACINYCONTROLPARAPROYECTOSMLTIPLES. ..............................................................................35 EL PORTAFOLIO DE PROYECTOS. ..............................................................................................................35 ALGUNASCONSIDERACIONESESPECIALESSOBRELAADMINISTRACINDEUNPORTAFOLIO ..................................36 LASECUENCIADELOSPROYECTOSDENTRODELPORTAFOLIO ..........................................................................36 ANLISISDELABRECHA .............................................................................................................................36 PLANIFICACIN Y CONTROL DE PROYECTOS POR CONTRATO. ...............................................................37 TIPOSDECONTRATO. .................................................................................................................................37 CONTRATOSDEPRECIOFIJO. .......................................................................................................................37 CONTRATOSDECOSTEMS. .......................................................................................................................37 COMOMANEJARLOSCAMBIOSENELPLANDELOSPROYECTOSPORCONTRATO. ................................................37 PLANIFICARYCONTROLARCONMETASBUROCRTICAS...................................................................................38 COMO ALCANZAR BUENOS RESULTADOS.................................................................................................38 PRINCIPIOS PARA TRIUNFAR COMO GERENTE DE PROYECTO. ................................................................38 LAS COMPETENCIAS BSICAS DEL MANAGER DE PROYECTO. ................................................................39 CAPITULO 2 ..............................................................................................................................................40 ETAPAS DE LOS PROYECTOS Y SUS COMPONENTES. .....................................................................40 GESTIN DE PROYECTOS. .....................................................................................................................40 PLANIFICACIN Y CONTROL ......................................................................................................................40 PLANIFICACIN Y CONTROL ......................................................................................................................41 ETAPAS DE UN PROYECTO. .......................................................................................................................41 LA OFERTA. ................................................................................................................................................43 FINALIDAD COMERCIAL. .............................................................................................................................44 ORIGEN TCNICO. ......................................................................................................................................44 LOS PROYECTOS INTERNOS. .....................................................................................................................44 LOS OBJETIVOS. .........................................................................................................................................45 EL CUARTO OBJETIVO................................................................................................................................46 CONTEXTO Y ESTRATEGIA. ........................................................................................................................46 EL CICLO DE VIDA.......................................................................................................................................46 ELEMENTOS DEL CICLO DE VIDA. ..............................................................................................................47 TIPOS DE MODELO DE CICLO DE VIDA. ......................................................................................................48 CICLODEVIDALINEAL: .........................................................................................................................49 CICLODEVIDACONPROTOTIPADO: ...................................................................................................49 CICLODEVIDAENESPIRAL: .................................................................................................................50 LOS PROYECTOS DE I+D. ...........................................................................................................................51 IDENTIFICACIN DE ACTIVIDADES. ............................................................................................................52 RELACIONES...............................................................................................................................................52 ESTIMACIN DE LA DURACIN DE LAS ACTIVIDADES...............................................................................53 LOS RECURSOS. .........................................................................................................................................53 Pg. 196 de 200 MANUAL TCNICO PMI - IT OBJETIVOS DE CADA FASE. .......................................................................................................................51
PLAZOS Y COSTES. ....................................................................................................................................53 TCNICAS DE PROGRAMACIN. ................................................................................................................54 DIAGRAMADEGANTT. .........................................................................................................................54 GRFICADEHITOS................................................................................................................................55 MTODODELCAMINOCRTICOCPM. .................................................................................................57 PROGRAMACINCONRECURSOSLIMITADOSYPROGRAMACINCONCOSTEMNIMO. .............57 TOMA DE DECISIONES. ...............................................................................................................................58 LAPENETRACINDELATOMADEDECISIONES. ................................................................................58 RACIONALIDAD. ...................................................................................................................................59 PROCESORACIONALDETOMADEDECISIONES. ................................................................................59 IMPORTANCIADELATOMADEDECISIONESENGRUPO. ..................................................................62 COMOLOGRARQUEFUNCIONELATOMADEDECISIONESENGRUPO: ...........................................63 LAGERENCIADEBETOMARDECISIONESDIFCILESYESOHACEIMPOSIBLEHACERFELICESA TODOS: ..................................................................................................................................................63 GESTIN DE LOS RECURSOS RRHH...........................................................................................................64 PERFILES DE UN EQUIPO DE TRABAJO. ....................................................................................................64 ORGANIZACINMATRICIALDELEQUIPODEPROYECTO.RELACINJEFEDEPROYECTOJEFE UNIDADFUNCIONAL: ...........................................................................................................................65 JEFE DE PROYECTO -- LA GERENCIA DE PROYECTOS. .............................................................................66 DEQUSEOCUPA: ...............................................................................................................................67 ELPERFILDEUNJEFEDEPROYECTO: .................................................................................................67 ESTILODIRECTIVOS: .............................................................................................................................67 CMOACTAN: ....................................................................................................................................68 CMOMEJORARLAEFICACIADELJEFEDEPROYECTO: ....................................................................69 EL EQUIPO DE TRABAJO. ...........................................................................................................................70 INTEGRACIN: ......................................................................................................................................71 SUBCONTRATACIN: ...........................................................................................................................71 CAPITULO 3 ..............................................................................................................................................73 TIPS PARA LA GESTIN DE PROYECTOS. ............................................................................................73 25 SECRETOS PARA MANTENER MOTIVADO A TU EQUIPO DE TRABAJO DE PROYECTOS ......................73 25 SECRETOS PARA MANTENER MOTIVADO A TU EQUIPO DE TRABAJO DE PROYECTOS ......................74 FOMENTANDO LA COMUNICACIN DEL PROYECTO ..................................................................................76 OFICINA DE PROYECTOS. ...........................................................................................................................79 TIPS PARA LA GESTIN Y ADMINISTRACIN DE PROYECTOS. .................................................................82 AUTORIDAD SIN AUTORITARISMO. ..............................................................................................................................82 DEBE SER PROACTIVO Y NO REACTIVO...........................................................................................................................82 RECOMPENSAR EL ESFUERZO. ..................................................................................................................................82 RESPONSABILIDAD. ............................................................................................................................................82 ENTREGARSE TOTALMENTE. .....................................................................................................................................83 METDICO. ....................................................................................................................................................83 ASUMIR LA REALIDAD. .........................................................................................................................................83 SENTIR Y MOSTRAR OPTIMISMO HACIA EL PROYECTO. ...........................................................................................................83 LDER DE PROYECTO PRECAVIDO VALE POR DOS. ................................................................................................................83 TOLERANCIA. ..................................................................................................................................................84 RESPETO POR LOS DEMS. .....................................................................................................................................84 EL DON DE SABER DELEGAR.....................................................................................................................................84 Cristian Bailey Consultor IT Pg. 197 de 200
IMPLEMENTACIN DEL AUTO APRENDIZAJE. .....................................................................................................................84 INVESTIGADOR. ................................................................................................................................................85 EL DON DEL BUEN NEGOCIADOR. ................................................................................................................................85 FLEXIBILIDAD. .................................................................................................................................................85 ACTUALIZACIN Y PROFESIONALIZACIN PERMANENTE. ..........................................................................................................85 AMPLIA VISIN.................................................................................................................................................86 EL ROL DE CONCILIADOR. ......................................................................................................................................86 NO IMPROVISES................................................................................................................................................86 COMUNCATE EFICIENTEMENTE CON TUS STAKEHOLDERS Y COLABORADORES: ....................................................................................87 ESTAR ATENTO EN LA ELECCIN DEL EQUIPO.....................................................................................................................87 APRENDE A DECIR QUE NO. .....................................................................................................................................87 RECOMENDACIONES AL EJECUTAR UN PROYECTO. ...............................................................................................................87 CUANDO EL RIESGO EN EL PROYECTO ES LA AUSENCIA IMPREVISTA DEL PROJECT MANAGER: .....................................................................87 IMPORTANCIA DEL REPORTE DE ESTADO DEL PROYECTO. .....................................................................88 LA DIRECCIN DEL PORTAFOLIO DE PROYECTOS TI. ...............................................................................89 UN MODELO DE PROCESOS PARA LA DIRECCIN DEL PORTAFOLIO. .................................................................................92 NECESIDAD DE UNA ESTRATEGIA DE IT PARA LA DIRECCIN DEL PORTAFOLIO. ....................................................................93 LA PUESTA EN MARCHA DE UN PORTAFOLIO DE PROYECTOS. ........................................................................................94 LAS CINCO ETAPAS DEL MODELO DE KERZNER SON: ...................................................................................................94 PRERREQUISITOS PARA LA IMPLANTACIN DE UNA DIRECCIN DE PORTAFOLIO. .................................................................95 SOFTWARE PARA LA DIRECCIN DEL PORTAFOLIO. ....................................................................................................95 PROCESOS CLAVE EN LA ADMINISTRACIN Y GESTIN DE PROYECTOS. ...............................................95 7 TIPS PARA ADMINISTRAR MLTIPLES PROYECTOS.............................................................................101 GREEN PROJECT MANAGEMENT. ............................................................................................................102 CAPITULO 4 ............................................................................................................................................105 DIMENSIONES DE LOS PROYECTOS. .................................................................................................105 MODELO PARA LA EVALUACIN Y ADMINISTRACIN DE PROYECTOS DE TECNOLOGAS DE LA INFORMACIN...........................................................................................................................................106 DIMENSIN1: GESTIN DE PROYECTOS. ...............................................................................................106 D1.1.GESTINDEPARTESINTERESADAS: ........................................................................................106 D1.2.GESTINDELALCANCE: ...........................................................................................................106 D1.3.ESTIMACINYCOSTEO: ...........................................................................................................107 D1.4.PLANEACINDERECURSOS: ..................................................................................................108 D1.5.CONTROLDEEJECUCIN: ........................................................................................................108 D1.6.GESTINDERIESGOS: ..............................................................................................................109 D1.7.GESTINDELASCOMUNICACIONES:.......................................................................................109 D1.8.GESTINDEADQUISICIONESYCONTRATOS: ........................................................................110 D1.9.GESTINDETALENTOHUMANO: ............................................................................................111 D1.10.GESTINDEDOCUMENTACIN: ............................................................................................111 DIMENSIN2:ASPECTOSTCNICOS. ....................................................................................................114 MANUAL TCNICO PMI - IT D2.1.DEFINICINDEREQUERIMIENTOS. .........................................................................................114 D2.2.INTEGRACINDEPRODUCTOSYSERVICIOS. .........................................................................114 D2.3.VALIDACIN. ............................................................................................................................115 D2.4.ADMINISTRACINDEPLATAFORMASTECNOLGICAS. .......................................................116 D2.5.RESTRUCTURACINDELASOLUCIN. ...................................................................................116 D2.6.VERIFICACIN. ..........................................................................................................................117 D2.7.GESTINDEENTREGABLES(PRODUCTOSYSERVICIOS). .....................................................117 DIMENSIN3:ALINEAMIENTOCONELNEGOCIO. ...............................................................................121 Pg. 198 de 200
D3.1.DIRECCIONAMIENTOESTRATGICOORGANIZACIONAL. ......................................................121 D3.2.PLANEACINESTRATGICADETI. ..........................................................................................122 INDICADORES Y CUANTIFICACIN DE LA GESTIN DEL PROYECTO. .....................................................125 CAPITULO 5 ............................................................................................................................................126 HERRAMIENTAS PARA LA GESTIN DE PROYECTOS. ......................................................................126 COMUNICACIN EFICAZ. .....................................................................................................................126 DEFINICIN DE METODOLOGAS RELACIONADAS. ..........................................................................126 TEMAS RELACIONADOS A LA GESTIN DE PROYECTOS. ..............................................................126 HERRAMIENTAS PARA LA ADMINISTRACIN.......................................................................................127 SIGLAS PMI ..........................................................................................................................................132 CONCEPTO DE RUP ..............................................................................................................................133 CONCEPTO DE ITIL ...............................................................................................................................133 CONCEPTO DE COBIT ..........................................................................................................................134 CONCEPTO DE PMI ...............................................................................................................................135 CONCEPTOS DE COMUNICACIN EFICAZ ............................................................................................137 7 ASPECTOS DE CONSULTOR INFORMTICO ......................................................................................172 CONCEPTO DE PETI PLANEACIN ESTRATGICA DE TI ....................................................................173 TICA PROFESIONAL EN TI ..................................................................................................................174 FRASES CELEBRES EN LA ADMINISTRACIN DE PROYECTOS: ..........................................................174 CONCLUSIONES. ..................................................................................................................................178 RECOMENDACIONES. ..........................................................................................................................178 GLOSARIO. ...........................................................................................................................................179
BIBLIOGRAFAS CONSULTADAS. .............................................................................................................193 DEDICATORIA: ................................................................................................................................200
Pg. 199 de 200
DEDICATORIA:
El presente manual tcnico se lo dedico a Dios, por haberme inspirado y permitirme tener el don de poder redactar este documento. A mi esposa e Hijas, a mis padres y hermanas, as como a mi familia entera. A mi abuelo Fernando por la paciencia que tuvo conmigo y lo que me enseo a mi abuela Raquel por haberme criado y amado como a un hijo ms. Especialmente a mi To Giovanni por que muchas veces me inspiro a seguir adelante. Cristian E. R. Bailey E. Lic. Informtica. Consultor TI.
Pg. 200 de 200

Administracion y Gestion de Proyectos Informaticos

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Administracion y Gestion de Proyectos Informaticos

Cargado por

Copyright:

Formatos disponibles

wwww.itcpcerbesa.

METODOLOGA PARA LA ADMINISTRACIN Y GESTIN DE PROYECTOS INFORMTICOS.

Cristian Bailey Consultor IT

MANUAL TCNICO PMI - IT

CAPITULO 1 LA ADMINISTRACIN DE PROYECTOS.

Cristian Bailey Consultor IT

MANUAL TCNICO PMI - IT

Implican acometer coordinadamente un conjunto de actividades interrelacionadas: un

EL CICLO DE VIDA DEL PROYECTO.

Nivel de Recursos en ($)

Proyecto de investigacin de mercado

Nivel de Recursos en ($)

Proyecto de investigacin cientfica

Cristian Bailey Consultor IT

DINMICA DEL CICLO DE VIDA DEL PROYECTO.

Seleccin del Proyecto Planificacin del Proyecto

Implementacin del proyecto

Control del Proyecto

A).- Seleccin del Proyecto:

Cristian Bailey Consultor IT

MANUAL TCNICO PMI - IT

Mtodos de evaluacin econmica de proyectos:

EL CONTROL DEL PROYECTO SE DIVIDE EN DOS REAS:

Cristian Bailey Consultor IT

MANUAL TCNICO PMI - IT

SI Continuar con el proyecto

Adaptar el proyecto para alcanzar los objetivos

Queremos cambiar nuestros objetivos NO SI

Queremos cambiar nuestros objetivos NO SI

Cambiar los objetivos y continuar con el proyecto Terminar el Proyecto

EL MANAGEMENT DE PROYECTO DE TECNOLOGA INFORMTICA Y SISTEMAS DE INFORMACIN

1 Leccin: Identificar y evitar las trampas.

Planificacin y Control Deficientes:

Cristian Bailey Consultor IT

2 Leccin: Cmo crear las acciones correctas

ASPECTOS A TENER EN CUENTA PARA EL DESARROLLO DE PROYECTOS

El divorcio entre la responsabilidad y la autoridad:

Cristian Bailey Consultor IT

MANUAL TCNICO PMI - IT

EL AMBIENTE COMPLETO DEL PROYECTO

Cristian Bailey Consultor IT

MANUAL TCNICO PMI - IT

LA POLTICA DE LOS PROYECTOS

Cristian Bailey Consultor IT

TRABAJAR CON GENTE CAPAZ

Quin manda aqu?

MANUAL TCNICO PMI - IT

Tendr una varianza de organigrama inaceptable?

Me apartar demasiado de las especificaciones?

El colaborador perfecto en un equipo de proyecto.

Trabajar con inteligencia.

Cristian Bailey Consultor IT

Cristian Bailey Consultor IT

MANUAL TCNICO PMI - IT

Cmo aplicar a los proyectos la teora de los tipos psicolgicos.

Cristian Bailey Consultor IT

MANUAL TCNICO PMI - IT

CMO ELEGIR UN ESTILO DE MANAGEMENT.

ESTRUCTURAR LOS EQUIPOS DEL PROYECTO Y DARLES COHESIN.

Cristian Bailey Consultor IT

MANUAL TCNICO PMI - IT

LA EFICIENCIA DEL EQUIPO.

COMO ESTRUCTURAR LOS EQUIPOS.