Disciplina para la administracin de

proyectos MSF v. 1.1

Microsoft Solutions Framework

Notas del producto

Para obtener ms informacin sobre MSF, vea: http://www.microsoft.com/msf/ (en ingls)

Resumen
Microsoft Solutions Framework (MSF) cuenta con un enfoque de equipo distribuido para
llevar a cabo la administracin de proyectos que mejora la responsabilidad y le permite
obtener una gran variedad de opciones de escalabilidad que abarcan desde proyectos
pequeos hasta proyectos muy grandes y complejos. Este documento describe cmo
funciona el enfoque de equipo distribuido y explica adems de qu manera los
administradores de proyectos se relacionan con el modelo de equipo MSF. Aunque la
administracin de proyectos resulta importante en proyectos pequeos, este documento se
centra en los proyectos grandes en los que estn ocupados amplios equipos. Si bien no
aborda todos los aspectos del campo de la administracin de proyectos, s proporciona
prcticas recomendadas sobre planeamiento y estimacin.

Informacin general sobre las plataformas

Para maximizar el xito de los proyectos relacionados con la tecnologa de la informacin
(TI), Microsoft ha puesto a su disposicin guas en forma de paquetes que le ayudan a
disear, desarrollar, implementar, operar y mantener de una manera efectiva soluciones
creadas a partir de la tecnologa de Microsoft. Estos conocimientos se han reunido a partir
de la experiencia obtenida en el desarrollo de software a gran escala de Microsoft, la
experiencia de los consultores de Microsoft en la direccin de proyectos para clientes
corporativos y los mejores conocimientos del sector de TI de todo el mundo. La gua se
divide en dos secciones de conocimientos, o plataformas, complementarias y perfectamente
integradas. Estas dos secciones son Microsoft Solutions Framework (MSF) y Microsoft
Operations Framework (MOF).

La creacin de una solucin empresarial que se ajuste a unos plazos y a un presupuesto

requiere contar con un enfoque contrastado. MSF proporciona soluciones contrastadas para
planear, disear, desarrollar e implementar soluciones de TI con xito. En contraposicin a
una metodologa prescriptiva, MSF ofrece una plataforma flexible y escalable que se ajusta
a las necesidades de cualquier organizacin o equipo de proyecto con independencia de su
tamao. La gua de MSF est formada por principios, modelos y disciplinas que sirven para
administrar personas, procesos y elementos tecnolgicos as como aspectos que tienen que
abordarse en la mayora de los proyectos.
Para obtener ms informacin sobre MSF, vea: http://www.microsoft.com/msf/ (en ingls)

MOF ofrece directrices tcnicas que permiten a las organizaciones lograr la confiabilidad,
la disponibilidad y compatibilidad de los sistemas ms importantes, as como la
manejabilidad de las soluciones de TI desarrolladas a partir de productos y tecnologas de
Microsoft. La gua de MOF aborda temas relacionados con las personas, los procesos, la
tecnologa y la administracin que pertenecen a entornos operativos complejos, distribuidos
y de TI heterogneos. MOF se basa en las prcticas recomendadas de la industria tal y
como se documenta en la IT Infrastructure Library (ITIL) de la Office of Government
Commerce (OGC) del gobierno del Reino Unido.

Para obtener ms informacin sobre MOF, vea: http://www.microsoft.com/mof/

Introduccin
Una de las caractersticas ms importantes de MSF es la ausencia de una funcin o nombre
de un puesto denominado administrador de proyectos. Esto puede parecer sorprendente en
una plataforma que aborda temas relacionados con cmo llevar a cabo con xito proyectos
de TI. Sin embargo, MSF da mucha importancia a la disciplina y las competencias
asociadas a la administracin de proyectos.

Este documento resume los aspectos clave de la disciplina de la administracin de

proyectos y muestra cmo MSF se enfrenta a estos aspectos. Tambin muestra cmo los
principios sobre los que se asienta MSF conducen a algunos conceptos y algunas prcticas
distintivas en la implementacin de la administracin de proyectos.

Tambin describe cmo la funcin de administracin de programas MSF ofrece tcnicas de

administracin de proyectos especializadas que ayudan a apoyar a todo el equipo y el modo
en que se distribuyen las actividades relacionadas con la administracin de proyectos entre
los distintos jefes de equipo MSF.

Este documento no tiene como objetivo ser una gua de cmo llevar a cabo la
administracin de proyectos, ni trata de explicar las tcnicas utilizadas por los
administradores de proyectos con experiencia. Por el contrario, muestra cmo los principios
de MSF conducen a un enfoque de administracin de proyectos en donde:

La responsabilidad de la administracin de los proyectos se reparte entre los

distintos jefes de equipo.
Los especialistas en la administracin de proyectos ofrecen un enfoque que se basa
en dar facilidades y ayuda, en lugar de en imponer el control sobre el resto del
equipo.

Es preciso leer el documento MSF Team Model (Modelo de equipo MSF) antes de leer el
presente documento.
Principios de MSF subyacentes
Si bien no se aborda en este documento, la disciplina de administracin de proyectos MSF
se aplica de alguna manera a todos los principios MSF, pero no se asocia directamente a lo
que se expondr a continuacin.

Responsabilidad clara-Responsabilidad compartida

El Modelo de equipo MSF se basa en la premisa de que cada funcin presenta una
perspectiva nica en el proyecto y que ninguna persona por s misma puede representar de
una manera satisfactoria todos los objetivos de calidad de todas las funciones. Sin embargo,
el cliente necesita una sola fuente de informacin que cuente con autoridad sobre el estado
del proyecto, las acciones y los problemas actuales. Para resolver este dilema, el equipo de
compaeros debe combinar una lnea clara de responsabilidad hacia el cliente con la
responsabilidad compartida con el fin de lograr el xito en general.

Dentro del equipo, cada funcin es responsable de todas las actividades que son necesarias
para lograr su propio objetivo de calidad.

Cada miembro del equipo es responsable del xito general del proyecto y de la calidad de la
solucin y se espera que contribuya con ideas y observaciones que se deriven de su
conocimiento incluso en reas en las que no es responsable de una manera personal.

En concreto, las funciones del equipo MSF comparten responsabilidad en muchos aspectos
de la administracin del proyecto, por ejemplo, la administracin del riesgo, la
administracin del tiempo, la administracin de la calidad, el planeamiento, la
programacin, la seleccin de los miembros del equipo y la administracin de los recursos
humanos.

Los equipos reforzados resultan ms efectivos

En un equipo efectivo, se anima a sus miembros a ofrecer sus propios compromisos y se
confa en que, en aquellas reas en las que ellos dependen de los compromisos de otras
personas, se cumplirn dichos compromisos. Igualmente, el cliente tiene el derecho a
asumir que el equipo cumplir su cometido y har planes sobre esta base. Cualquier retraso
o cambio debe comunicarse lo ms pronto posible.

Un equipo MSF debe ofrecer a sus miembros la autorizacin que stos necesitan para
cumplir su cometido. Esto tiene un profundo impacto en la funcin de la administracin del
proyecto en su capacidad de supervisar el progreso. Sin autorizacin y compromiso, los
administradores de equipos deben comprobar continuamente y doblemente si los miembros
del equipo siguen en la buena direccin. Una vez estn seguros de que informarn de
cualquier retraso tan pronto como se conozca, los jefes de equipo pueden tener una funcin
de mayor ayuda que ayude a los miembros del equipo a obtener acceso a su verdadero
puesto, ofrecindoles al mismo tiempo ayuda y asistencia. La supervisin del progreso se
distribuye entre los distintos miembros del grupo y se convierte en una funcin de ayuda en
vez de en una funcin de control.

Conceptos clave
Para entender el enfoque MSF en la administracin de proyectos, es importante comprender
la manera en que MSF define los siguientes conceptos y trminos.

Disciplinas en MSF
MSF reconoce distintas reas de conocimiento no tecnolgico que son competencias
importantes de todas las funciones del modelo de equipo MSF. Estas competencias se
denominan disciplinas. Para obtener ms informacin, vea el documento MSF Team Model
(Modelo de equipo MSF).

Actualmente, MSF ha abordado tres disciplinas. Estas tres disciplinas son: administracin
del riesgo, administracin de la disponibilidad y administracin de proyectos.

MSF reconoce que estas disciplinas han desarrollado las prcticas recomendadas que estn
bien asentadas en muchas industrias, no slo en las de la tecnologa de la informacin (TI).
A menudo, estas soluciones pueden aplicarse a operaciones de TI y a otros procesos
empresariales as como a proyectos de TI. En lugar de volver a inventar estas prcticas,
MSF resume lo que los jefes de equipo deben conocer de estas disciplinas y agrega la
perspectiva interna obtenida por los equipos de Microsoft a lo largo de estos ltimos aos.

Para llevar a cabo el trabajo de una manera efectiva, los jefes de todas las funciones del
equipo MSF deben tener un nivel de competencia adecuado en cada disciplina.

En qu consiste la administracin de proyectos?

Antes de describir la administracin de proyectos de TI, es de una gran ayuda entender la
definicin de administracin de proyectos, con independencia del tipo de proyecto del que
se trate.

Un proyecto es una empresa temporal que cuenta con un principio y un final definidos cuyo
objetivo es crear un producto o servicio nico. La administracin de proyectos es un rea
de conocimiento, tcnicas y herramientas que se utilizan para lograr los objetivos del
proyecto dentro de unos parmetros de calidad, costos, plazos y lmites previamente
acordados. (i)

En algunas empresas y en algunos pases, el trmino programa se utiliza para describir

grupos de proyectos que se coordinan conjuntamente. Para evitar confusiones con el grupo
de funciones de equipo MSF denominado administracin de programas, haremos referencia
a un grupo de proyectos como portafolio de proyectos.
MSF categoriza las siguientes reas de responsabilidades, tcnicas y actividades en la
administracin de proyectos (ii).
rea de administracin de proyectos
Planeamiento/seguimiento/control de
cambios del proyecto
Administracin de los mbitos
Administracin de la programacin
Administracin de costos
Administracin de los recursos humanos
Administracin de las comunicaciones
Administracin del riesgo
Adquisicin
Administracin de la calidad
Descripcin
Integracin y sincronizacin de los planes
sobre el proyecto; establecimiento de los
procedimientos y los sistemas usados para
administrar y realizar un seguimiento de los
cambios.
Definicin, divisin del mbito de trabajo
(mbito del proyecto); administracin de los
aspectos del proyecto.
Generacin de programas a partir de las
estimaciones del equipo, secuenciacin de
tareas, adecuacin de los recursos a las
tareas, aplicacin de tcnicas de estadstica,
mantenimiento del programa.
Preparacin de estimaciones de costos en
base a las estimaciones temporales del
equipo; creacin de informes sobre el
progreso y anlisis; anlisis de los factores de
riesgo de los costos, anlisis de los valores.
Planeamiento de recursos, creacin de
equipos, resolucin de conflictos,
planeamiento de la disponibilidad (para el
proyecto).
Planeamiento de las comunicaciones (equipo,
cliente/patrocinador, usuarios, participantes),
creacin de informes sobre el estado del
proyecto.
Facilitacin y direccin del proceso de
administracin de los riesgos del equipo;
mantenimiento de la documentacin sobre
los riesgos.
Solicitacin de pujas de proveedores por
servicios o hardware/software; preparacin
de solicitudes para propuestas,
administracin de proveedores o proveedores
secundarios; administracin y negociacin de
contratos, acuerdos; apertura de pedidos de
compra y aprobacin de facturas.
Planeamiento de la calidad, determinacin de
los estndares que vayan a usarse,
documentacin de los criterios de calidad y
 de los procesos de medicin de la misma.

Si bien en este documento no se ofrece una gua completa sobre cada una de las reas
mencionadas anteriormente, s se proporcionan determinadas prcticas recomendadas para
MSF.

La administracin de proyectos no slo la realizan los

administradores de proyectos
En el lenguaje de hoy en da, el trmino administracin de proyectos puede utilizarse para
describir tanto una funcin como un rea de tcnicas y conocimientos. Por ejemplo, piense
en las siguientes frases "Los encargados de la administracin del proyecto dijeron que lo
tendran acabado en esta fecha" y "Las agencias espaciales tienden a contar con excelentes
funciones de administracin de proyectos".

Esta distincin es importante porque la administracin de proyectos, como actividad, la

realizan varias personas que no son administradores de proyectos.

Tal y como se utiliza en MSF, administracin de proyectos siempre se utiliza para hacer
referencia a un grupo especfico de reas de conocimientos y tcnicas que se han citado
anteriormente, no a una funcin o al nombre de un puesto. El trmino administrador de
proyectos se utiliza para describir a alguien que est especializado en la administracin de
proyectos.

Administracin de proyectos y procesos especficos de la

TI
En general, la administracin de proyectos est formada por reas de conocimiento y
tcnicas que se aplican ampliamente a cualquier sector de la industria que realice proyectos.
Cada sector de la industria (por ejemplo, el sector aeroespacial, la construccin, la TI, etc.)
tiene sus propios procesos, fases, funciones y prcticas que funcionan mejor en ese sector
en concreto. Para lograr el xito de los proyectos, estos procesos especficos de cada
industria deben complementarse con prcticas generales aplicadas a la administracin de
proyectos.

MSF ofrece procesos y prcticas recomendadas para los proyectos de la TI. Su relacin con
la disciplina de la administracin de proyectos se muestra en la Figura 1.

Si su explorador no admite los marcos en lnea, haga clic aqu para abrir una pgina
independiente.

Figura 1 Relacin de MSF con la disciplina de la administracin de proyectos

El dominio concreto de la industria en este caso son las cinco fases del modelo del proceso
MSF. Un ejemplo de una actividad relacionada con la administracin de proyectos
especfica de un sector de la industria son las prcticas recomendadas para realizar un
seguimiento de los errores. Las reas de conocimiento genricas de la administracin de
proyectos se sitan a la izquierda. Un ejemplo son las prcticas recomendadas para
administrar contratos o realizar un seguimiento de los presupuestos. La interseccin
representa ciertas prcticas de la administracin de proyectos que son tpicas de MSF. A
continuacin se presentan estas prcticas.

Caractersticas de la administracin de proyectos MSF

A continuacin se presentan y se explican ms en detalle tres caractersticas distintivas del
enfoque MSF:

La mayora de las responsabilidades de la funcin del administrador de proyectos se

incluyen en el grupo de funciones de la administracin de programas MSF.
En proyectos grandes en los que se requieren equipos MSF ms grandes, las
actividades relacionadas con la administracin del proyecto tienen lugar en varios
niveles.
Algunos proyectos grandes o complejos necesitan un administrador de proyectos o
un equipo de administracin de proyectos especializado.

La funcin del administrador de proyectos est incluida

en la administracin de programas
El grupo de funciones de la administracin de programas MSF incluye las reas de
responsabilidad funcional que se muestran a continuacin. En proyectos ms pequeos,
normalmente un solo administrador de programas se encarga de todas las responsabilidades
funcionales. A medida que aumenta el tamao y la complejidad de un proyecto, este grupo
de funciones se divide en dos reas de especializacin: una de ellas se encarga de la
arquitectura y las especificaciones y la otra de la administracin de proyectos.

Cmo la administracin de programas se integra con los

jefes de proyecto
Para entender cmo funciona la administracin de proyectos en MSF, es necesario entender
cmo el modelo de equipo se hace ms grande, dirige el planeamiento, se comunica y toma
decisiones. Para obtener ms informacin, vea el documento MSF Team Model (Modelo de
equipo MSF).

Para ser ms precisos, el modo en que se distribuye la administracin del proyecto depende
en gran parte de la escala y la complejidad de ste.
MSF es una plataforma altamente escalable que puede utilizarse en proyectos pequeos en
los que participen de dos a tres personas, o en proyectos muy grandes. Los equipos de
creacin de productos internos de Microsoft estn formados por cientos e incluso miles de
miembros. MSF ha generalizado las lecciones sobre la organizacin de los equipos en
Microsoft para que puedan utilizarse en una gran variedad de proyectos de TI.

Gran parte de la escalabilidad de MSF se debe al modelo de equipo. Este modelo de equipo
puede escalarse de dos maneras principales:

1. Abstrayendo las funciones del equipo como un grupo de responsabilidades

funcionales, en lugar de como descripciones de trabajos especficos. De esta
manera, las responsabilidades de cada funcin no estn sujetas a los lmites de una
sola persona. Una funcin puede ampliarse a grupos de funciones y cada uno de
ellos se especializa en un grupo ms especfico de responsabilidades. Una o ms
personas pueden llevar a cabo estas funciones ms especializadas.
2. Usando equipos de producto y calidad y equipos funcionales en diversas
combinaciones para crear cualquier nmero de posibles estructuras de grandes
equipos. A continuacin se describen los equipos de producto y calidad y los
equipos funcionales.

Equipos funcionales
Los equipos funcionales son equipos secundarios que existen dentro de una funcin y que
se forman cuando las tareas de una funcin son suficientemente grandes y requieren
recursos exclusivos. Un aspecto clave de un equipo funcional no es simplemente que la
funcin requiere ms de una persona para llevarse a cabo, sino que existe una delimitacin
de las tareas entre sus miembros. La Figura 2 muestra un ejemplo de este concepto.

El jefe de equipo es el punto de integracin con el resto del equipo. Los jefes de equipo
tienen algunas responsabilidades en la administracin del proyecto al nivel de su equipo
secundario.
Figura 2 Equipo funcional de ejemplo para la experiencia del usuario

Equipos de producto y calidad

Los equipos de producto y calidad son equipos secundarios multidisciplinares que se
organizan en torno a una caracterstica concreta de la solucin. Estos equipos se crean a
partir de seis funciones que componen el modelo de equipo. La Figura 3 muestra un equipo
de producto y calidad. La funcin de administracin de programas tambin es el jefe de
equipo que proporciona el punto de integracin con el equipo ms grande. La estructura del
equipo de producto y calidad es una buena candidata para crear componentes bastantes
pequeos de equipos secundarios remotos o "distantes" para la solucin.

Si su explorador no admite los marcos en lnea, haga clic aqu para abrir una pgina
independiente.

Figura 3 Ejemplo de equipos de producto y calidad

Escalado de las funciones de administracin de proyectos

La Figura 4 muestra cmo se gestionan las actividades relacionadas con la administracin
de proyectos en tres niveles de la escala del proyecto. En el proyecto A donde todas las
funciones las llevan a cabo aproximadamente seis personas o menos, todas las actividades
relacionadas con la administracin de proyectos las gestiona la administracin de
programas. Esto no significa que las otras funciones no tengan ninguna influencia en la
administracin del proyecto. De hecho, lo que significa es que son responsables de planear,
estimar e identificar los riesgos de sus reas respectivas.

Si su explorador no admite los marcos en lnea, haga clic aqu para abrir una pgina
independiente.

Figura 4 Un enfoque escalable para la administracin de proyectos

En el proyecto B, la mayora o todas las funciones las llevan a cabo los equipos
secundarios, cada uno de ellos dirigido por un jefe de equipo. Los jefes de equipo se
encargan de la administracin del proyecto de sus respectivos equipos secundarios. El
grupo de funciones de administracin de proyectos posee actividades relacionadas con la
administracin del proyecto en general. Recuerde que los equipos de producto y calidad no
se muestran en el grfico, pero tambin son equipos secundarios. Puesto que cada equipo de
producto y calidad es multidisciplinar, cada uno de ellos cuenta con un jefe de
administracin de programas.
El proyecto C es similar al proyecto B, si bien tiene unos riesgos especiales debido a su
tamao o complejidad. Un proyecto completo, tal y como se usa en MSF, significa que el
proyecto tiene muchos riesgos relacionados con los siguientes factores:

Tamao o costo grandes.

Equipos dispersos geogrficamente.
Los miembros de los equipos pertenecen a varias empresas, organizaciones o
proveedores secundarios.
Planeamientos o presupuestos fijos o muy limitados.
Temas contractuales o legales que requerirn tcnicas y tiempo para enfrentarse a
ellos.

Para mitigar estos riesgos, el grupo de funciones de administracin de programas dispone

de un equipo funcional que incluye administradores de proyectos y diseadores de
soluciones especializados. Recuerde que el umbral del riesgo no ser el mismo para todas
las organizaciones y para todos los proyectos. Lo que resulta muy costoso para una
organizacin, puede que no sea tan costoso para otra. Depende totalmente de la evaluacin
del riesgo que se realice al principio del proyecto.

Responsabilidades de la administracin de proyectos

La seccin anterior abordaba cmo se distribuyen las actividades relacionadas con la
administracin de proyectos entre los miembros del equipo en distintos niveles de escala y
complejidad. Esta seccin describe estas actividades.

La Figura 5 describe las responsabilidades de la administracin de proyectos que

pertenecen a los jefes de equipo de cada funcin y administracin del programa. Los
administradores de proyectos especializados que trabajan en un proyecto complejo (por
ejemplo, el proyecto C que se muestra en la Figura 4) se centran en las mismas reas tal y
como se muestra de la administracin de programas, slo de manera exclusiva. Recuerde
que a menudo la misma rea de responsabilidades queda cubierta en el nivel del proyecto y
en el nivel del equipo secundario.

Si su explorador no admite los marcos en lnea, haga clic aqu para abrir una pgina
independiente.

Figura 5 Responsabilidades de la administracin de proyectos para los jefes de

equipo

Jefes de equipo
Los jefes de equipo preparan los planes para sus equipos secundarios y en ellos describen
cmo realizar el trabajo, realizar un seguimiento del trabajo real y confrontarlo con los
planes, administrar los mbitos y los cambios, asignar recursos a tareas especficas del
equipo secundario y coordinar las comunicaciones internas de los equipos secundarios. Los
jefes de equipo llevan a cabo estas actividades con la participacin y las sugerencias de
cada uno de los miembros de los equipos secundarios. Al mismo tiempo que participan en
la identificacin del riesgo en general, los jefes de equipo son especficamente responsables
de la identificacin de los riesgos en el rea de conocimiento de sus funciones.

La Figura 5 muestra tres lugares en los que las responsabilidades de los jefes de equipo
difieren del patrn de los otros:

1. La administracin de costos de un proyecto normalmente se centraliza como una

responsabilidad de la administracin de programas. Repartir esta funcin entre los
jefes sera confuso y probablemente creara caos.
2. Las responsabilidades de adquisicin recaen sobre la administracin de programas
y/o versiones, pero no sobre los otros jefes de equipo. La administracin de
programas se encarga de la contratacin de la mayora de los servicios relacionados
con el proyecto y de diversos tipos de compras. Un ejemplo sera la subcontratacin
de una empresa de diseo de pginas Web para que formara parte del equipo. La
administracin de versiones, como representante de las operaciones de TI del
equipo, se encarga de la adquisicin de hardware, software y activos materiales para
la solucin que est siendo creada as como del desarrollo del equipo y del entorno
del laboratorio de pruebas.
3. La administracin de las comunicaciones a nivel general del proyecto se reparte
entre la administracin de programas y la administracin de productos. La
administracin de productos se encarga de crear y enviar el plan de comunicaciones
al cliente, los participantes y a cualquier audiencia externa. La administracin de
programas planea y es responsable de las comunicaciones en el proyecto, por
ejemplo, la creacin de informes sobre el estado del proyecto, la celebracin de
reuniones con el equipo y similares. La administracin de las comunicaciones
tambin incluye planear las comunicaciones, asignar los puntos de contacto
designados e informar del progreso realizado a personas ajenas al equipo.

Administracin de programas
Adems de ser responsable de la arquitectura de la solucin a un alto nivel y de escribir
especificaciones funcionales (tal y como se describe en el modelo de equipo), a la
administracin de programas le pertenecen todas las reas de la administracin de
proyectos del proyecto en general.

La administracin de programas integra los planes del equipo secundario en el plan

maestro, sincroniza los programas y administra las dependencias que existen en el equipo.

La gran ventaja de asignar la responsabilidad tanto del diseo de la solucin como de las
especificaciones funcionales en la misma funcin que la responsabilidad de programacin y
costos es la siguiente: fija un equilibrio entre la tendencia a recrearse en exceso en el diseo
y las implicaciones en cuanto a costos y programacin que ello supone.

Administracin de proyectos grandes y complejos

A medida que un proyecto se hace ms grande o complejo, puede que resulte una tarea
abrumadora administrar especificaciones funcionales, actualizar programaciones, enviar
comunicaciones al equipo, informar del progreso del proyecto y llevar a cabo otras
actividades relacionadas con la administracin del mismo. Para enfrentarse a esto, a
menudo es recomendable dividir las responsabilidades del grupo de funciones de
administracin de proyectos en una arquitectura de la solucin y una funcin de
administracin de proyectos exclusiva.

Servicios administrativos del proyecto

En algunos aspectos, en un gran proyecto se realizan las mismas tareas que en un pequeo
negocio: realizar un seguimiento de las finanzas, adquirir suministros y servicios,
administrar el rendimiento del personal, proporcionar orientacin y formacin,
acondicionar las instalaciones de trabajo del equipo y el alojamiento del mismo, etc. Sin
embargo, en proyectos muy grandes, realizar el seguimiento del estado, los costos y los
plazos del proyecto de una manera rutinaria lleva mucho tiempo. Para permitir al
administrador de proyectos centrarse en los asuntos ms apremiantes, la mayora de las
actividades de la administracin del proyecto se delegan en un puesto (o asistente para el
proyecto) administrativo del proyecto. Los servicios administrativos del proyecto tambin
proporcionan soporte a jefes de equipo y ayudan a mantener los programas del equipo y
otras actividades relacionadas con la administracin de proyectos.

Responsabilidad del cliente

Los clientes a menudo desean un nico punto de responsabilidad que ayude a lograr el xito
del proyecto en general. Algunas organizaciones recurren a un administrador de proyectos
para desempear esta funcin. Esto a veces est justificado en el caso de proyectos grandes
y complejos, pero este enfoque puede suponer una falta de equilibrio en cuanto a la
responsabilidad de las distintas funciones del equipo, lo que ocasionar un mal
funcionamiento del proyecto. MSF se acomoda a la necesidad del cliente de contar con un
solo punto de autoridad para asegurar su satisfaccin y al mismo tiempo conservar la
responsabilidad compartida entre los miembros del equipo.

En el equipo MSF, cada funcin del equipo es internamente responsable de sus propias
actividades. Adems, las personas que trabajan en cada funcin normalmente son
responsables ante alguna estructura de administracin ajena al equipo del proyecto. Debido
a que MSF no asume que todos los miembros del equipo trabajan en la misma empresa u
organizacin, estas rutas de responsabilidad conducen a cualquier organizacin, grupo o
departamento al que pertenecen esas personas.

Los puntos clave aqu son los siguientes:

No hay nada definitivo sobre este tema. Ms all del equipo del proyecto inmediato,
existen muchas posibles diferencias en las estructuras organizativas de creacin de
informes y en las relaciones de los servicios.
 Identifique las rutas de responsabilidad de su proyecto. Clarifique quin es
responsable de los distintos aspectos del proyecto, ms all del mismo equipo.

El modelo de equipo MSF otorga responsabilidad al cliente de las siguientes maneras:

La administracin de productos mantiene una relacin con el cliente y acta como

defensor de ste. El objetivo del rendimiento de esta funcin es lograr la
satisfaccin del cliente.
El objetivo del rendimiento de la administracin de programas es enviar con xito el
proyecto dentro de los lmites del mismo.
La administracin de productos y programas funciona de una manera integrada para
satisfacer las necesidades del cliente dentro de las restricciones del proyecto. Ambas
comparten la responsabilidad de lograr el xito en general del proyecto aunque sus
funciones luchan por conseguir objetivos diferentes.
Si surgen problemas que la administracin de productos y programas no pueden
resolver, estos problemas se trasladan a la ruta de responsabilidad nica del
proyecto en general.

Recomendaciones seleccionadas para los equipos MSF

Las siguientes prcticas recomendadas para la administracin de proyectos van dirigidas a
los jefes de equipo MSF y a la administracin de programas. Estas prcticas se
corresponden con algunas, no todas, las reas de responsabilidad de la administracin de
proyectos que aparecen en la Figura 5.

Administracin de los mbitos

El objetivo de la administracin de mbitos es asegurar que el proyecto identifica todo el
trabajo que se necesita para completar la solucin y que no se desva hacia actividades
situadas fuera del mbito sin una revisin y aprobacin preliminar.

mbito durante la previsin

En el proceso inicial del proyecto, es necesario identificar y documentar el mbito amplio
de un proyecto.

Durante la fase de previsin de MSF, el equipo genera una visin ilimitada de la solucin.
A continuacin, se identifica el mbito de la primera versin. Esto se describe en el
documento de visin/mbito y es aprobado por el equipo, el cliente y los participantes antes
de que el proyecto pueda continuar. Durante esta fase, el mbito slo se entiende en
trminos muy amplios, al nivel de descripcin de caractersticas.

mbito de la solucin y del proyecto

El mbito puede referirse al mbito de la solucin y a la del proyecto. El mbito de la
solucin es la suma de todas las caractersticas y los elementos a entregar que deben
crearse. El mbito del proyecto es la suma de todo el trabajo que debe realizarse para
ofrecer la solucin.

El equipo utiliza el proceso de diseo MSF para definir el mbito de la solucin.

Definicin del mbito

En la fase de planeamiento, el mbito del proyecto en general debe subdividirse en partes
ms pequeas y manejables. Este proceso clarifica las reas especiales que no se encuentran
en ese mbito determinado. Normalmente, en estas reas hay un riesgo especial de que se
produzcan malentendidos.

Durante la definicin del mbito, el equipo identifica los tipos de tareas y tcnicas que se
necesitan para crear cada caracterstica y los elementos a entregar. Esto se documenta en
una estructura de divisin de trabajo (WBS) que se describe posteriormente en este
documento.

Control del cambio de mbito

Una vez el mbito ha sido definido y se ha establecido su lnea base, el equipo considera
que lo tiene bajo control. Los cambios en el mbito deben ser revisados y aprobados tanto
por el equipo como por el cliente.

Parte de un buen control del cambio implica tomar buenas decisiones sobre las
compensaciones. El tringulo de tres variables interdependientes MSF y la matriz de
compensaciones son herramientas tiles para facilitar el cambio de una manera controlada.

Para obtener ms informacin, vea el documento Modelo de proceso MSF.

Preparacin de los planes

El planeamiento como actividad se lleva a cabo a lo largo del proyecto. Durante la fase de
previsin, el equipo establece el enfoque de alto nivel necesario para crear los elementos a
entregar del proyecto.

Por ejemplo, el enfoque de pruebas describe los tipos de pruebas, las herramientas y las
tcnicas que se necesitan. En funcin del tamao del proyecto, el documento puede ocupar
solamente una o dos pginas, o incluso un prrafo.

Si bien los planes se detallan y actualizan en cada fase, la mayor parte del planeamiento se
produce durante la fase de planeamiento MSF.

La secuencia general de los procesos durante esta fase es la siguiente:

 Proceso de diseo (qu crear?)
Proceso de planeamiento (cmo lo crear?)
Desarrollo de la programacin (cundo lo crear?)

Estos procesos pueden superponerse de algn modo, pero es preciso establecer la lnea base
del proceso anterior antes de que el siguiente pueda lograr detalles significativos. Esta
seccin se centrar en el proceso de planeamiento.

Reutilizacin de documentos
Los equipos de proyectos estn sometidos a una presin constante para que minimicen el
tiempo y los gastos del planeamiento. Cmo se pueden obtener ventajas de un buen
planeamiento minimizando al mismo tiempo la carga del planeamiento?

La respuesta es recogiendo y volviendo a usar de una manera inteligente los documentos

del planeamiento. Las organizaciones que se den cuenta de que los documentos de
planeamiento son propiedad intelectual valiosa invertirn en organizar y mantener estos
documentos en almacenes a los que pueda obtenerse acceso fcilmente.

Antes de crear un nuevo plan, los equipos siempre deben buscar cualquier cosa que ya se
haya realizado. Una vez se ha completado un proyecto, es preciso archivar los documentos
del mismo en una ubicacin para que los equipos del futuro puedan volver a usarlos.

Planes del proyecto

En MSF, los planes de proyectos hacen referencia a un grupo de documentos que describen
cmo se van a completar los elementos del proyecto que deben entregarse. Las
especificaciones funcionales describen qu se crear. El plan de proyecto maestro es una
sucesin integrada de planes de equipo para cada funcin. Cada funcin del equipo cuenta
con planes que describen cmo completarn sus elementos a entregar.

MSF no prescribe una lista de planes del tipo "en un tamao entra todo" que todos los
proyectos deben tener. La siguiente lista predeterminada cubre las reas de planeamiento
habituales que se encuentran en los proyectos de desarrollo de software y de
implementacin de infraestructuras. En proyectos ms pequeos, es posible combinar
algunos de estos planes. Es posible que algunos proyectos necesiten ms planes.

Tipo de plan Funcin predominante

Plan de comunicaciones Administracin de productos
Plan de desarrollo Desarrollo
Plan de formacin Experiencia del usuario
Plan de seguridad Desarrollo, administracin de versiones
Plan de pruebas Pruebas
Plan de presupuesto Administracin de programas
Plan de educacin del usuario
Plan de implementacin
Plan de compras e instalaciones
Plan piloto
Experiencia del usuario
Administracin de versiones
Administracin de versiones, Administracin
de programas
Administracin de versiones

Estructura de divisin del trabajo

Una WBS es una agrupacin de elementos de trabajo del proyecto orientados a la entrega
que organiza y define el mbito total del proyecto (iii). Consiste en un esquema del trabajo
que va a realizarse. El trabajo no incluido en una WBS bien construida est fuera del
mbito del proyecto. Los jefes de equipo y la administracin de programas utilizan la WBS
como herramienta en la administracin de proyectos para crear planes y programaciones.

En MSF, la creacin de la WBS es un ejercicio de colaboracin en el que participan todas

las funciones del equipo. Cada funcin es principalmente responsable de la definicin de
los detalles del trabajo de su rea respectiva. En proyectos ms grandes, los equipos
secundarios (equipos funcionales o de producto y calidad) puede que necesiten aportar
ideas sobre el trabajo que es necesario llevar a cabo. Los jefes de equipo documentan los
resultados de la sesin de aportacin de ideas y ofrecen los resultados al equipo (jefe)
principal. A continuacin, la administracin de programas sincroniza estas contribuciones
en una WBS comn.

Ventajas
El valor de una WBS se entiende mejor si se piensa en l como un grupo de datos en lugar
de como un documento especfico. Estos datos, cuando se combinan con los datos de otros
proyectos, se utilizan para crear planes, programas, presupuestos y otros elementos del
proyecto que se han de entregar. Es posible visualizar una WBS como una lista con sangra
o un diagrama de bloque que puede crearse en diversas herramientas tales como hojas de
clculo, programas de procesador de texto o software para la administracin de proyectos.

La WBS ofrece ventajas por lo siguiente:

Estimacin. Proporciona una lista bsica de las tareas de las que deben realizarse
estimaciones. Las estimaciones proporcionadas determinan el costo y la
programacin.
Recursos. Las necesidades de recursos y de plantilla se conocen clarificando los
trabajos que deben llevarse a cabo. Ello tambin ayuda demostrar las necesidades de
los recursos si los participantes del proyecto piden una justificacin.
Secuenciacin. Proporciona una lista bsica de las tareas que pueden analizarse para
conocer las restricciones de dependencias y recursos que pueden desarrollarse en
una programacin.
Identificacin de riesgos. Ayuda al equipo a considerar cada tarea al identificar los
riesgos.
 Responsabilidad. Puede utilizarse para generar una matriz de responsabilidades.

Capacidad de seguimiento existente entre una WBS, las

especificaciones funcionales y un plan de proyecto
maestro
Existe una relacin de la que puede realizarse un seguimiento entre las especificaciones
funcionales, un plan de proyecto maestro y la WBS. Refleja la relacin existente entre los
elementos a entregar y las tareas que se necesitan para crear dichos elementos.

Por cada caracterstica o componente de las especificaciones funcionales, la WBS

confecciona un listado de las tareas asociadas a la creacin de ese elemento que debe
entregarse. La manera en que las caractersticas o los componentes se agrupan en
especificaciones funcionales no es la misma en que sus tareas asociadas aparecen en la
WBS.

Si una caracterstica no tiene una tarea asociada a ella en algn lugar de la WBS,
posteriormente puede "colarse" en el proceso de estimacin, lo que posiblemente se
traducir en una programacin o un presupuesto no realista.

El plan de proyecto maestro y la WBS se complementan. La WBS lista cada una de las
tareas de una manera breve. Las descripciones detalladas de cmo deben llevarse a cabo las
tareas, las barras de calidad y las tareas secundarias detalladas o las listas de comprobacin
se documentan en los planes.

La Figura 6 muestra de una manera esquemtica cmo una WBS puede ser una herramienta
potente para mantener la capacidad de seguimiento entre especificaciones, planes y
programaciones.

Si su explorador no admite los marcos en lnea, haga clic aqu para abrir una pgina
independiente.

Figura 6 La WBS ofrece capacidad de seguimiento entre especificaciones, planes y

programaciones

Creacin de una estructura de divisin del trabajo

Cada equipo se encarga de identificar actividades especficas que son necesarias para crear
los elementos del proyecto que deben entregarse. Diversas funciones o equipos secundarios
se encargan de poseer y realizar un seguimiento de los detalles de las actividades mediante
listas de comprobacin y planes.
En MSF, el nivel ms bajo de actividad aparece en el plan de proyecto maestro, pero no en
la WBS. Estas actividades se convierten en tareas suficientemente grandes sobre las que
vale la pena realizar seguimientos e informes al nivel del proyecto en general que es la
WBS.

Los jefes de equipo se renen con sus equipos funcionales para dividir los requisitos del
trabajo. Trabajando en equipo a travs de las especificaciones funcionales y de las
especificaciones de otros elementos que deben entregarse, se identifica el trabajo necesario
y se divide en actividades y tareas ms pequeas. A este proceso se le conoce como
divisin o descomposicin del trabajo.

Uno de los resultados del proceso de administracin del riesgo MSF son tareas adicionales
que responden a los riesgos (a los que a veces se denominan "amenazas") o planes de
contingencia y actividades. Estas tareas deben agregarse a la WBS, a lo estimado, a lo
planeado y a lo programado de la misma manera que el resto de tareas. Considere la opcin
de programar las sesiones de divisin del trabajo del equipo y las sesiones de aportacin de
ideas para el riesgo de manera conjunta.

El primer nivel de la WBS debe contener una fase del ciclo de vida del proyecto. El modelo
de proceso MSF se presta a s mismo a esto perfectamente. MSF sugiri que los objetivos
importantes provisionales estn vinculados a la finalizacin o el establecimiento de la lnea
base de los elementos a entregar. Los objetivos importantes provisionales tambin forman
un segundo nivel natural. Por debajo de este nivel, se identifican todos los elementos para
entregar y se desglosan las tareas necesarias para crear cada uno de ellos. A este proceso se
le denomina descomposicin del trabajo o de las tareas.

Directrices para la descomposicin de tareas

stas son las directrices que se recomiendan al llevar a cabo la descomposicin de tareas:

Puede realizarse una estimacin de ellas de una manera realista.

No se cree que lleven menos de un da ni ms de 40 (en el caso de proyectos de TI).
Tienen una conclusin y un elemento a entregar significativos.
Pueden completarse sin grandes interrupciones.
Pueden asignarse a una persona responsable de su realizacin.
Pueden dividirse ms que otras a ciertos niveles.
Las actividades de alto riesgo pueden dividirse ms que las de bajo riesgo.
Excepto en el caso del nivel uno o dos, utilice una frase formada por sujeto y verbo
para describir la tarea. Por ejemplo, utilice "Disear esquema de base de datos" en
lugar de simplemente "Esquema de base de datos".
Contiene entre tres y cinco niveles en el formulario de esquema.
La WBS evoluciona de manera interactiva durante el curso del proyecto, pero
normalmente adquiere la forma durante la fase de planeamiento.
Estimacin en mbitos que van de lo particular a lo
general
Las estimaciones de los proyectos de TI deben realizarlas aqullos que estn programados
para realizar el trabajo. La estimacin en mbitos que van de lo particular a lo general es un
proceso para desarrollar e integrar estimaciones de varios miembros del equipo.
Proporciona las siguientes ventajas:

Mayor exactitud. Las estimaciones realizadas por aqullos que harn el trabajo son ms
precisas ya que la persona que realiza las estimaciones ya tiene experiencia en la
realizacin de trabajos similares.

Responsabilidad. Las personas que desarrollan sus propias estimaciones de trabajo se

sienten ms responsables de su trabajo. Tambin se sienten ms responsables del xito que
pueden tener al cumplir las estimaciones que han realizado.

Reforzamiento del equipo. Tener fechas fijadas por el equipo en contraposicin a fechas
dictadas por la administracin refuerza al equipo ya que los plazos se establecen en funcin
de estimaciones que los miembros del equipo pueden aceptar como realistas.

Integracin de las estimaciones de los equipos

Cada jefe de equipo, junto con sus equipos secundarios, es responsable de preparar las
estimaciones del tiempo necesario para completar los elementos que se han de entregar
pertenecientes a su rea de funciones. Por ejemplo, el jefe de desarrollo prepara
estimaciones para los desarrolladores; el jefe de la experiencia del usuario prepara
estimaciones para los elementos que deben entregarse de la experiencia del usuario (EU) y
as sucesivamente, siempre escuchando los comentarios de su equipo.

La funcin de la administracin de programas facilita el proceso de realizacin de

estimaciones del equipo e integra todas las estimaciones en una programacin y un
presupuesto maestros.

Estimacin en los proyectos de software

El costo de los proyectos de TI recae principalmente en el trabajo, por lo que las
estimaciones del trabajo se convierten en datos esenciales y necesarios para generar
estimaciones de costos y tiempo.

Creacin de expectativas adecuadas

Las estimaciones crean expectativas sobre ciertos resultados que se producirn en el futuro.
Por ello, crear expectativas razonables sobre la exactitud de una estimacin es tan
importante como la tcnica utilizada para generar dicha estimacin. Los grupos funcionales
de administracin de programas y productos deben trabajar duro para garantizar que se
tienen expectativas comunes sobre lo siguiente:

Las estimaciones dependen de la especificacin. El desarrollo de soluciones de TI es muy

parecido a construir su propia casa. Es imposible saber cunto costar sin antes haber
definido perfectamente todos sus elementos. Esto no significa que las especificaciones son
lo nico necesario para realizar una estimacin del proyecto. Otros elementos del trabajo
tales como la comunicacin con el cliente, las reuniones sobre el proyecto, los informes
sobre el estado ocupan tiempo y tambin deben tenerse presentes en las estimaciones.

Preprese para las compensaciones. Abordar el tringulo de tres variables

interdependientes y establecer las prioridades predeterminadas usando la matriz de
compensaciones ayuda al equipo y al cliente a crear expectativas comunes.

Es inevitable no tener alguna imprecisin. Debido a que el desarrollo de una solucin es un

proceso de mejora continua, las estimaciones tienen un margen para la variacin.

Vuelva a realizar una estimacin tras lograr un objetivo importante. El equipo debe
comprometerse a proporcionar una serie de estimaciones ms precisas a medida que avanza
el proyecto.

Incertidumbre y exactitud de las estimaciones

Las estimaciones en el desarrollo de software son un proceso de mejora gradual. La Figura
7 muestra el llamado "cono de incertidumbre" (convergencia de estimaciones) de las
estimaciones en el desarrollo de software. En la fase temprana del proyecto, el intervalo de
variacin de las estimaciones con respecto al costo real es muy grande. Este intervalo se
hace ms pequeo a medida que avanza el proyecto.

Tenga presente que al lograr objetivos importantes aprobados en el documento de

visin/mbito, la estimacin puede ser demasiado baja por un factor de 2, o demasiado alta
por un factor de 0,5. Los valores de los datos especficos que se muestran, y que se han
tomado de una encuesta realizada a mediados de los 90, no deben aplicarse de una manera
demasiado literal. Lo importante es entender el orden de la magnitud de la variacin en
cada fase.

La leccin en este caso es que durante la fase de previsin, el equipo desarrolla intervalos
de estimaciones (que a veces se denominan "estimaciones aproximadas") de tiempo y
costos. Nunca ofrezca una estimacin de costos o tiempo que sea invariable durante esta
fase. Es preciso tener claro que estas estimaciones pueden variar por un gran factor al lograr
objetivos importantes aprobados en los documentos de visin/mbito.

Si su explorador no admite los marcos en lnea, haga clic aqu para abrir una pgina
independiente.
Figura 7 Cono de incertidumbre

Fuente: Adaptado del documento Cost Models for Future Lifecycle Processes: COCOMO
2.0 (Modelos de costos para procesos de ciclo de vida prximos: COCOMO 2.0) Boehm,
et. al., 1995 (iv).

Estimacin en el nivel ms bajo de la divisin de tareas

Hay varias maneras de preparar las estimaciones de esfuerzo en el nivel de tareas. Todas
estas maneras comienzan con la divisin de cada tarea de la WBS en actividades ms
pequeas. Esto se realiza en el nivel de los equipos secundarios y lo dirige cada jefe de
equipo.

A continuacin, se genera una estimacin por cada una de las actividades del nivel ms
bajo. Estas estimaciones se agregan para realizar la estimacin de las distintas tareas de la
WBS.

La revisin de los datos reales de proyectos anteriores es uno de los mejores modos de
sentar las bases de las estimaciones. Las organizaciones inteligentes recogen y analizan
estos datos. Muchas actividades del proyecto cuentan con indicadores de la industria que
pueden proporcionar buenas pruebas comparativas.

Una tcnica recomendada ms precisa es generar estimaciones de tres parmetros por cada
actividad del nivel bajo. Las estimaciones de tres parmetros incluyen un valor de
estimacin optimista, pesimista y muy probable para cada tarea. Los criterios deben
clarificar lo que significan estas estimaciones. El grado pesimista no tiene que significar
necesariamente el peor de todos los escenarios posibles. Por el contrario, las estimaciones
optimistas y pesimistas deben basarse en riesgos razonables y probables.

Una vez las actividades del nivel bajo se suman a las actividades del nivel WBS, hay tres
valores de estimacin por tarea. Los jefes de equipo envan esta informacin a la
administracin de programas para que lleven a cabo el anlisis de los costos y, a
continuacin, utilizan los datos de las estimaciones para preparar programaciones.

Anlisis PERT
Una vez se han reunido las estimaciones de todas las tareas en la WBS, la administracin
de programas (o un administrador de proyectos especializado) aplica los anlisis
estadsticos para ajustar la estimacin de tiempo en general. Existen varias tcnicas para
esto, pero la ms usada es PERT (tcnica de revisin de evaluacin de programas). PERT
toma estimaciones de tres parmetros y calcula el promedio de la distribucin. Esto se
utiliza para hacer una prediccin de la fecha de finalizacin ms probable, en lugar del
nico valor de la estimacin ms probable. Tambin proporciona un intervalo de resultados
de las estimaciones que tiene como base las variaciones de todas las tareas de la ruta crtica.
La descripcin completa de la PERT se encuentra fuera del mbito de este documento. Sin
embargo, las herramientas de administracin de proyectos, tales como Microsoft
Project, permiten realizar anlisis PERT.

Recomendaciones sobre las programaciones

La administracin de las programaciones incluye los procesos necesarios para garantizar
que el proyecto se finalice a tiempo.

Secuenciacin de tareas
Una vez se han documentado y se han realizado las estimaciones de las tareas y las
actividades del proyecto en la WBS, se identifican las dependencias entre ellas. Por
ejemplo, no es posible completar el borrador de la documentacin del usuario de una
caracterstica sin antes completarse la especificacin funcional que describe esa
caracterstica. Las dependencias deben identificarse a los niveles de tareas ms pequeos.

Lucha contra el tiempo

Utilice lmites de tiempo internos para mantener la presin sobre el equipo del proyecto con
el fin de dar prioridad a caractersticas y actividades; a esta tcnica se le conoce como
"lucha contra el tiempo". Esto no debe usarse de mala manera para reducir de una manera
arbitraria las estimaciones de tiempo del equipo. Una lucha contra el tiempo correcta
comienza con una estimacin de tiempo razonable y con la idea de que es posible que sea
necesario recortar algunas caractersticas para ajustarse al lmite del tiempo.

Programacin basada en los riesgos

Las caractersticas o los componentes de alta prioridad con ms riesgo deben programarse
en la fase temprana del proyecto. De este modo se ampla al mximo el tiempo disponible
para reaccionar ante problemas.

Administracin del tiempo adicional

Agregue tiempo adicional a los plazos del proyecto para permitir al equipo acomodarse a
los problemas y cambios que se produzcan de manera inesperada. La cantidad de tiempo
adicional que debe aplicarse depende del nivel de riesgo. Al evaluar los riesgos en la fase
inicial del proyecto, es posible evaluar los riesgos ms probables para conocer el impacto
que stos tendrn en los plazos y cmo se pueden compensar usando tiempo adicional.

Un modo de pensar en el tiempo adicional es como si fuese una estimacin para tareas y
eventos desconocidos. No importa la experiencia que tenga el equipo, no todas las tareas de
los proyectos pueden conocerse ni se puede realizar una estimacin de ellas con antelacin.
Sin embargo, es prcticamente cierto que habr riesgos en algunos proyectos y tendrn un
impacto en el proyecto, y que las acciones correctoras necesarias para responder al riesgo
necesitarn ms tiempo.

stas son las directrices recomendadas para hacer un buen uso del tiempo adicional.

El tiempo adicional no debe agregarse inflando las estimaciones para las tareas
individuales. Puesto que el trabajo aumenta para ocupar el tiempo asignado para
hacer dicho trabajo (un efecto denominado Ley de Parkinson), el tiempo adicional
ser absorbido por las tareas planeadas, no por los eventos no planeados.
El tiempo adicional debe programarse como si fuese cualquier tarea. Normalmente,
el tiempo adicional se asigna inmediatamente antes de lograr objetivos importantes,
especialmente los ltimos. Siempre debe situarse en la ruta crtica del proyecto. La
ruta crtica es la cadena ms larga de tareas dependientes de un proyecto y
determina directamente la duracin del proyecto.
A medida que aumenta el tiempo adicional durante el curso del proyecto, la
Administracin de programas debe realizar un seguimiento y conservar
cuidadosamente la cantidad restante. El tiempo adicional es un conjunto
compartido, por lo que slo debe asignarse cuando se solicite.
Si se agrega una caracterstica, o si se suprimen recursos del proyecto, no compense
estos recursos usando el tiempo adicional. Si lo hace, su capacidad de compensar
los riesgos se ver reducida consecuentemente. Negocie las caractersticas, los
recursos y los plazos usando el tringulo de tres variables interdependientes.
Si se utiliza todo el tiempo adicional, asegrese de que todo el equipo sepa que
cualquier interrupcin o retraso es probable que tenga un efecto "cascada" y ponga
en peligro la fecha de finalizacin.

Conclusin
MSF proporciona una manera escalable de asegurar que se cumplen las funciones de la
administracin de proyectos tanto de los proyectos ms pequeos como de los proyectos
ms grandes y complejos. Este enfoque evita el exceso de burocracia en los proyectos ms
pequeos al mismo tiempo que proporciona una estructura de administracin de proyectos
suficientemente grande para proyectos ms grandes y complejos.

Notas finales
(i) PMI, Inc., A Guide to the Project Management Body of Knowledge, 2000 Edition (Gua
sobre el conocimiento principal necesario en la administracin de proyectos, Edicin de
2002) (Newtown Square, PA: Project Management Institute, 2000), p. 4-6. Para obtener
definiciones similares usadas en Europa y el Reino Unido, vea tambin G Caupin, H
Knopfel, P Morris, E. Motzel, O Pannenbacker, IPMA Competence Baseline (Bremen,
Germany: International Project Management Association, 1999), p. 23, y Central Computer
and Telecommunications Agency, Managing Successful Projects with Prince2
(Administracin satisfactoria de proyectos con Prince2), (London: UK Stationery Office,
1998), p. 7.
(ii) Adaptacin de A Guide to the Project Management Body of Knowledge (Gua sobre el
conocimiento necesario en la administracin de proyectos), p. 39. IPMA hace referencia a
28 reas de conocimiento, que incluye las nueve descritas por PMI. Prince2 incluye ocho
componentes de la administracin de proyectos, de los que slo tres de ellos se asignan
directamente a PMI. Las reas de IPMA se asignan perfectamente tanto a PMI como a
Prince2.

(iii) A Guide to the Project Management Body of Knowledge (Gua sobre el conocimiento
necesario en la administracin de proyectos), p. 4-6. WBS tambin se define en IPMA
Competence Baseline (Lnea base de la competencia IPMA), p. 34.

(iv) Adaptado a MSF del documento Cost Models for Future Lifecycle Processes:
COCOMO 2.0 (Modelos de costos para procesos de ciclo de vida prximos: COCOMO
2.0) Boehm, et. al., 1995. Anteriormente se adapt en Steve McConnell, Rapid
Development (Desarrollo rpido) (Redmond, WA : Microsoft Press, 1996), p. 168.

La informacin que contiene este documento representa la visin actual de Microsoft

Corporation acerca de los temas tratados en el momento de su publicacin. Dado que
Microsoft debe responder a las condiciones variables del mercado, este documento no debe
interpretarse como un compromiso por parte de Microsoft, y Microsoft no puede garantizar
la exactitud de la informacin presentada con posterioridad a la fecha de publicacin.

La finalidad de este documento es nicamente informativa. MICROSOFT NO OTORGA

GARANTAS EXPRESAS, IMPLCITAS O ESTATUTARIAS SOBRE LA
INFORMACIN DE ESTE DOCUMENTO.

Es responsabilidad del usuario el cumplimiento de las leyes de derechos de autor aplicables.

Ninguna parte de este documento puede ser reproducida, almacenada o introducida en un
sistema de recuperacin, o transmitida de ninguna forma, ni por ningn medio (ya sea
electrnico, mecnico, por fotocopia, grabacin o de otra manera) con ningn propsito, sin
la previa autorizacin por escrito de Microsoft Corporation.

Microsoft puede ser titular de patentes, solicitudes de patentes, marcas registradas, derechos
de autor u otros derechos de propiedad intelectual sobre los contenidos de este documento.
La posesin de este documento no le otorga ninguna licencia sobre estas patentes, marcas
registradas, derechos de autor u otros derechos de propiedad intelectual, a menos que se
prevea en un contrato de licencia por escrito de Microsoft.

2002 Microsoft Corporation. Reservados todos los derechos.

Microsoft y Project son marcas comerciales o marcas registradas de Microsoft Corporation

en los Estados Unidos o en otros pases.

Otros nombres de productos y compaas reales mencionados aqu pueden ser marcas
registradas de sus respectivos propietarios.
Nmero de pieza: 602-i404a