Microsoft Solution Framework

Lectura 03: Microsoft Solution Framework
Disciplina para la administracin de proyectos MSF v. 1.1

Microsoft Solutions Framework
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
Interbank
Instructor: MCT Luis Dueas

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.
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.
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
Interbank

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.
Interbank
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.
Interbank

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
Interbank
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
Administracin de la programacin
Administracin de costos
Administracin de los recursos humanos
Administracin de las comunicaciones
Administracin del riesgo
Adquisicin
Administracin de la calidad
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
Interbank

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
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.
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
Interbank

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).
Interbank

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.
Interbank
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.
Figura 3
Interbank
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.
Figura 4 Un enfoque escalable para la administracin de proyectos
Interbank

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
Interbank

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.
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
Interbank

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
Interbank

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
Interbank

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.
Interbank
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.
Interbank
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?
Interbank

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
Plan de comunicaciones
Plan de desarrollo
Plan de formacin
Plan de seguridad
Plan de pruebas
Plan de presupuesto
Plan de educacin del usuario
Plan de implementacin
Plan de compras e instalaciones
Plan piloto
Interbank
Funcin predominante
Administracin de productos
Desarrollo
Experiencia del usuario
Desarrollo, administracin de versiones
Pruebas
Experiencia del usuario
Administracin de versiones
Administracin de versiones,
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
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.
Interbank
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,

especificaciones funcionales y un plan de proyecto maestro
las
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.
Interbank
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.
Interbank

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".
Interbank
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.
Interbank
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
Interbank

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
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.
Figura 7 Cono de incertidumbre
Interbank
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.
Interbank

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.
Interbank
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.
Interbank
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.
Interbank
Metodologa Microsoft Solution Framework: Ejemplo

Fase 1 - Estrategia y alcance
En esta fase deberan tener lugar los siguientes trabajos:
Elaboracin y aprobacin del Documento de Alcance y Estrategia definitivo:
debe ser un documento de consenso con la participacin del mayor nmero de
agentes implicados en el proyecto. En este documento quedarn definitivamente
reflejadas las funcionalidades y servicios que, ineludiblemente, debe ofrecer la
solucin a implantar.
Formacin del Equipo de Trabajo y distribucin de competencias y
responsabilidades: generalmente se definen como reas principales la de Diseo de
Arquitectura, Pruebas de Laboratorio, Documentacin, Logstica y Coordinacin.
Elaboracin del Plan de Trabajo: deben marcarse fechas y contenidos para esta
fase y las siguientes. Los mecanismos y protocolos de intercambio de informacin y
coordinacin deben quedar suficientemente bien establecidos y consensuados.
Elaboracin de la matriz de Riesgos y Plan de Contingencia: los principales
riesgos detectados deben tener un plan de mitigacin y actuacin y revisarse con
periodicidad.
Para un proyecto de migracin a Windows 2000 podra estimarse que los trabajos
indicados pueden requerir en torno a 20 jornadas de trabajo y la intervencin de un
Consultor de Microsoft junto con el equipo de trabajo que formen El cliente y el
Partner.
Fase 2 - Planificacin y Prueba de Concepto

Deben alcanzarse los siguientes objetivos e hitos:
Documento de Planificacin y Diseo de Arquitectura: es el documento
principal, donde se describen en detalle los aspectos funcionales y operativos de la
nueva plataforma. La aprobacin de este documento es el hito principal de esta fase,
y supone la directriz ltima de todos los trabajos tcnicos, que, a partir de ese
momento, deben ser consistentes con esta Gua. Si en el curso de las fases sucesivas
fuera necesario revisar estos contenidos, se deber hacer por acuerdo y
conocimiento de todo el equipo de trabajo y se llevar un registro de versiones que
permita hacer un seguimiento adecuado de estas revisiones.
Documento de Plan de Laboratorio - Prueba de Concepto: la descripcin del
contenido del laboratorio de prueba de concepto, los diversos escenarios a simular,
los criterios de validez, el control de incidencias y las mtricas de calidad son
objetivos a cubrir en este documento. Es un documento dinmico, en el que se
recoge la idea y la experiencia prctica al llevarla a cabo en entorno controlado y
aislado. La etapa de prueba de laboratorio concluye cuando la maqueta ofrece todos
los servicios y funciones descritos en el Documento de Alcance y Estrategia, y su
grado de estabilidad y rendimiento es considerado como "suficiente".
Habitualmente, en las propuestas de pre-venta no se pueden indicar con precisin
parmetros como el esfuerzo tcnico, tiempo o coste definitivo que puede suponer esta
Interbank

fase. De otras experiencias anteriores se puede obtener una relacin de trabajos slo a
ttulo orientativo, y que debe ser revisado y acordado por todas las partes:
Fase
Servicios
Bsicos de Red,
diseo de sites
y Active
Directory
Seguridad y
Accesos
Administracin
Servicios y
aplicaciones
corporativas
Interbank
Jornadas
10
Personas
Contenido
(mnimo)
Instalacin de la
plataforma
El
Windows 2000
Partner: 2 Definicin de
El
parmetros y puesta
cliente: 1 en servicio de SBR:
Active Directory,
DHCP y DDNS
Documento
Documento de instalacin
de Windows 2000 y
Servicios Bsicos de Red
10
Definicin de
grupos de usuarios.
Nomenclatura
El
Modelo de
Documento de definicin
Partner: 2
seguridad de acceso. del mtodo de validacin y
El
Pruebas con
seguridad lgica.
cliente: 2
MSCHAP, Kerbers
y Smart Card (si
est disponible).
15
Definicin de las
tareas
administrativas
relevantes:
mantenimiento de
usuarios y grupos,
El
copia de seguridad,
Partner: 2
uso de auditora,
El
recuperacin de
cliente: 1
mquinas,
reinstalacin de
software,
etcDefinicin de
perfiles y polticas
de usuario y grupo
Documento gua de
administracin.Documento
Plan de Contingencias
(Disaster & Recovery Plan)
10
Instalacin de
servicios y
aplicaciones
corporativas en la
El
nueva plataforma y
Partner: 2 procedimientos para
El
conseguirlo:
cliente: 2 Configuracin de
recursos
compartidos (File &
Print)Distribucin
de Software
Documento de migracin e
implantacin de
aplicaciones y servicios
corporativos (estrategia e
implantacion)
Alta
Disponibilidad
y tolerancia a
fallos
Conectividad y
modalidades de
acceso remoto
Windows
Terminal
Server
Servicios web y
provisin de
contenidos por
la red
Escalabilidad
10
Escenarios de
El
operacin 24x7 y
Partner: 2
Documento de pruebas de
balanceo de carga
El
Alta Disponibilidad
con Windows 2000
cliente: 1
AS.
El
Partner: 2
El
cliente: 1
Instalacin y
configuracin de
El
Terminal Server.
Partner: 2
Configuracin del
El
perfil de acceso
cliente: 2
administrativo y
aplicaciones
Instalacin y
configuracin de
El
IIS5.0 para
Documento de
Partner: 2
provisin de
implantacin y servicios de
El
servicios on-line de Intranet
cliente: 2
Intranet (formacin,
documentacin, etc)
Definicin de los
escenarios de
crecimiento de la
El
nueva arquitectura
Partner: 2
descrita y
El
requerimientos de
cliente: 2
infraestructura,
administracin y
seguridad
Configuracin de la
DMZ, firewalls,
proxys y medios
fsicos de acceso
Documento de
configuracin de la
Infraestructura de Acceso
Remoto
Documento de Instalacin,
configuracin y escenarios
de uso de W2000TS.
Documento de pruebas de
escalabilidad
El cmputo de jornadas para la relacin de actividades descritas (que como se observa

slo recogen las relativas a la Planificacin y Diseo, y deja aparte las necesarias para
elaborar el plan de Migracin), ofrecera este resultado:
Jornadas totales: 80 (aprox. 4 meses)
Jornadas / tcnico del PARTNER: 150 jornadas (2 personas)
Jornadas / tcnico del CLIENTE: 110 jornadas (max. 2 personas)
Fase 3 - Estabilizacin
La solucin implantada en la maqueta se pasa a un entorno real de explotacin,
restringido en nmero de usuarios y en condiciones tales que se pueda llevar un control
efectivo de la situacin. Los hitos y objetivos fundamentales de esta fase son:
Seleccin del entorno de prueba piloto: se acordar la composicin y ubicacin
del conjunto de mquinas y usuarios que entrarn en la prueba. Esta seleccin se
Interbank

recomienda que se haga atendiendo a la mayor variedad posible de casos, de manera
que puedan aflorar el mximo de incidentes potenciales en el menor tiempo posible.
La dimensin de la muestra tiene tambin que calcularse, sin perder de vista que la
prueba piloto no es el despliegue propiamente, sino una fase de observacin en la
que es absolutamente crtico establecer unos cauces efectivos de tratamiento de los
errores.
Gestin de Incidencias: aunque esta labor se habr iniciado en la fase anterior, el
xito de la prueba piloto depender de que se forme un sistema de recogida de
incidentes (helpdesk o similar), de atencin al usuario (formacin, consultas) y de
resolucin de problemas y documentacin de los mismos (versionado de la
plataforma).
Revisin de la documentacin final de Arquitectura: el documento de
Planificacin y Diseo de Arquitectura se puede ver alterado parcialmente como
resultado de esta fase. El documento final, aprobado por consenso, supone el
principal documento del Proyecto y la culminacin de los trabajos de diseo, al
menos en sus lneas principales. Este documento se considerar definitivo cuando la
solucin puesta en marcha se muestre estable y el nmero de incidencias graves (de
intervencin o de resolucin) sea nulo y la cantidad de las consideradas leves quede
por debajo de un lmite establecido en las Mtricas de Calidad.
Elaboracin de la documentacin de Formacin y Operaciones: con vistas al
soporte post proyecto y los programas de formacin a usuarios y administradores, en
esta fase deben elaborarse las Guas de Usuario, de Administracin, las "paso-apaso", y otros cuyos contenidos deben acordarse previamente.
Elaboracin del Plan de Despliegue: se debe consensuar la fecha de finalizacin
de la fase Piloto, y las condiciones de calidad que debe cumplir la solucin final
para inciiar el despliegue. En el Plan deben identificarse las fases, estrategia de
implantacin, fechas, tareas a realizar, procedimientos de validacin y mtodo de
control de incidencias.
Elaboracin del Plan de Formacin: con anterioridad al despliegue definitivo,
debe haberse aprobado el Plan de Formacin orientado a usuarios finales y
administradores, y debe hacerse compatible con los ritmos acordados en el Plan de
Despliegue.
El tiempo necesario para abordar esta fase es variable y depende en parte de factores
ajenos a la complejidad de la propia solucin, como es la adecuada seleccin del
entorno de prueba y el momento del ao en que tenga lugar (evitando que coincida con
periodos de vacaciones o puntas de trabajo crticas como Fin de Ao). En proyectos de
similar envergadura se ha llegado al momento "Error Free Version" en 30 jornadas de
trabajo (aproximadamente mes y medio) con una muestra de 50 usuarios.
Fase 4 - Despliegue
Se llevarn a cabo en esta fase los planes diseados en la anterior, principalmente el de
despliegue y el de formacin. Los principales trabajos e hitos a conseguir son, en este
caso, adems de los obvios (implantacin de la plataforma, puesta en servicio de todas
las funciones, formacin a los usuarios y administradores), los siguientes:
Continuacin con las labores de recepcin de incidencias, clasificacin, tratamiento,
resolucin y distribucin de fixes o intervencin on-site.
Interbank

Registro de mejoras y sugerencias, funcionalidades no cubiertas y novedades a
incorporar en sucesivas versiones de la plataforma, incluyendo mejoras aportadas
por los fabricantes de software (nuevas versiones o Service Packs, por ejemplo)
Revisin de las Guas y manuales de usuario, rectificacin de errores y obtencin de
los documentos de formacin definitivos.
Entrega de los documentos definitivos acordados como "deliverables" en la fase de
Vision Scope.
Revisin (si procede) de la matriz de riesgos, las mtricas de calidad y
establecimiento de los estndares de calidad y SLA definitivos.
Finalmente, entrega del Proyecto y cierre del mismo, con o sin apertura de nuevo
proyecto en base a la informacin y experiencia obtenidos.
La duracin fase de despliegue, puesto que debe planificarse, no puede establecerse a
priori. Depende de numerosos factores externos al propio proyecto (incluyendo factores
de oportunidad poltica o de negocio) que pueden retardar o acelerar la conclusin.
La experiencia demuestra que no hay una relacin directa entre nmero de mquinas y
tiempo necesario para el despliegue. Los factores ms relevantes en el clculo suelen ser
la dispersin o concentracin geogrfica, la complejidad del proceso de migracin, el
grado de automatizacin alcanzado, la experiencia y nivel de los tcnicos que realizan la
operacin y condicionantes de calendario, a menudo con restricciones no tcnicas, sino
de otros tipos (las fechas-objetivo suelen marcarse por criterios de oportunidad de
negocio).
Interbank

Microsoft Solution Framework

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Microsoft Solution Framework

Uploaded by

Copyright:

Available Formats

Lectura 03: Microsoft Solution Framework

Disciplina para la administracin de proyectos MSF v. 1.1

Informacin general sobre las plataformas

Instructor: MCT Luis Dueas

Lectura 03: Microsoft Solution Framework

Government Commerce (OGC) del gobierno del Reino Unido.

Instructor: MCT Luis Dueas

Lectura 03: Microsoft Solution Framework

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

Principios de MSF subyacentes

Responsabilidad clara-Responsabilidad compartida

Instructor: MCT Luis Dueas

Lectura 03: Microsoft Solution Framework

Los equipos reforzados resultan ms efectivos

Instructor: MCT Luis Dueas

Lectura 03: Microsoft Solution Framework

recomendadas que estn bien asentadas en muchas industrias, no slo en las

En qu consiste la administracin de proyectos?

de proyectos es un rea de conocimiento, tcnicas y herramientas que se

Administracin de los mbitos

Instructor: MCT Luis Dueas

Lectura 03: Microsoft Solution Framework

Administracin de los recursos humanos

Administracin de las comunicaciones

Administracin del riesgo

los aspectos del proyecto.

La administracin de proyectos no slo la realizan los administradores

Instructor: MCT Luis Dueas

Lectura 03: Microsoft Solution Framework

Administracin de proyectos y procesos especficos de la TI

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

Instructor: MCT Luis Dueas

Lectura 03: Microsoft Solution Framework

Caractersticas de la administracin de proyectos MSF

La mayora de las responsabilidades de la funcin del administrador de

La funcin del administrador de proyectos est incluida en la

Cmo la administracin de programas se integra con los jefes de

Instructor: MCT Luis Dueas

Lectura 03: Microsoft Solution Framework

Instructor: MCT Luis Dueas

Lectura 03: Microsoft Solution Framework

Figura 2 Equipo funcional de ejemplo para la experiencia del usuario

Equipos de producto y calidad

Ejemplo de equipos de producto y calidad

Lectura 03: Microsoft Solution Framework

Escalado de las funciones de administracin de proyectos

Figura 4 Un enfoque escalable para la administracin de proyectos

Instructor: MCT Luis Dueas

Lectura 03: Microsoft Solution Framework

Tamao o costo grandes.

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

Responsabilidades de la administracin de proyectos

Instructor: MCT Luis Dueas

Lectura 03: Microsoft Solution Framework

Figura 5 Responsabilidades de la administracin de proyectos para los jefes

Instructor: MCT Luis Dueas

Lectura 03: Microsoft Solution Framework

Instructor: MCT Luis Dueas

Lectura 03: Microsoft Solution Framework

Administracin de proyectos grandes y complejos

Servicios administrativos del proyecto

Responsabilidad del cliente

Instructor: MCT Luis Dueas

Lectura 03: Microsoft Solution Framework