principios de desarrollo de aplicaciones. agenda qué es msf? introducción al modelo de equipos...

Principios de Desarrollo de Aplicaciones

Agenda Qué es MSF?

Introducción al Modelo de Equipos

Administración de riesgos

Introducción al modelo de Procesos

Hito Aprobación de Visión

Hito Aprobación del Plan de Proyectos

Hito Alcance Completo

Hito Liberación

Resumen

Qué es MSF?

Porcentaje de Proyectos fracasados

Proyectos de Desarrollo de Aplicaciones

Modificados

Exitosos

Fracasados 28%28%46%46%

26%26%

“Cuando un proyecto falla, rara vez es por cuestiones técnicas.”

Jim Johnson, The Standish Group

Las principales causas de los fracasos

Separación de objetivos y negocios

Separación de negocios y tecnología

Carencia de Lenguaje y proceso comunes

Falla al comunicar y actuar como equipo

Procesos que son inflexibles a los cambios

Principios del Desarrollo de Aplicaciones

Apoya lo que considera Microsoft que son las mejores prácticas y principios del desarrollo de aplicaciones

Es un miembro de la familia Microsoft Solutions Framework

Representa un framework, no una metodología

Se focaliza en la gente y en los procesos, no en la tecnología

Origen

Grupos deProductosMicrosoft

todo mundo

Grupos deProductosMicrosoft

todo mundo

Información Tecnológica

Microsoft

Información Tecnológica

Microsoft

Servicios de

ConsultoríaMicrosoft

Servicios de

ConsultoríaMicrosoft

Partners de Microsoft

Partners de Microsoft

Mejores Prácticas

Curriculum MSF

ConstruirPlanificar

Gerenciar

MSF

Introducción alModelo de Equipo

Equipos Jerárquicos

Las dificultades del trabajo en equipos jerárquicos

Dificultades en Equipos Jerárquicos

Alta sobrecarga de comunicaciones

Malos entendidos por comunicaciones indirectas

Objetivos confusos de equipo y roles

Miembros no integrados del equipo

Alta sobrecara de procesos

Metas del equipo para el éxito

Clientes satisfechos

Entregas dentro de las restricciones del proyecto

Entregas bajo especificaciones basadas en los requerimientos del usuario

Entregas después de tratar todas los temas conocidos

Rendimiento incrementado del usuario

Despliegue prolijo y administración en curso

El éxito total requiere éxito en cada objetivo

Cada objetivo debe ser igualmente valorado

Cada objetivo requiere una disciplina que este enfocada a dicho objetivo

Cada disciplina esta contenida en un rol

Objetivos valorados equitativamente se corresponden con roles igualmente valorados, creando un equipo de pares

Entendiendo los objetivos

Equipo de pares

Es un equipo cuyos miembros se relacionan como iguales

Cada miembro tiene roles y responsabilidades específicos

Potenciar a los individuos en sus roles

Responsabilizar a los miembros por el éxito de sus roles

Conducir las desiciones sobre la base del concenso

Otorgar a todos los miembros del equipo un riesgo en el éxito del proyecto.

Modelo de Equipo para el Desarrollo de Aplicaciones

Gerente deDesarrolloGerente deDesarrollo

DesarrolladorDesarrollador

TestingTesting

GerenteDe Logística


FormaciónDe UsuariosFormación

De Usuarios

Gerente de Producto

Gerente de Producto

Comunicación

Rol del Gerente de Producto

Actuar como un cliente dentro del equipo

Actuar como equipo avocado a el cliente

Conduce la visión compartida del proyecto

Maneja expectativas del cliente

Desarrolla, mantiene, y ejecuta el caso de negocio

Conduce la identificación y priorización de las funcionalidades

Desarrolla, mantiene y ejecuta el plan de comunicaciones.

GerenteDe Producto

GerenteDe Producto

Rol del Gerente de Desarrollo

Conduce el proceso global

Maneja la asignación de recursos

Maneja el cronograma y reporta el estado del proyecto

Maneja el alcance y la especificación del producto

Facilita la comunicación y la negociación del equipo

Conduce los cambios críticos de decisiones en su globalidad.

Gerente deDesarrolloGerente deDesarrollo

Rol del Desarrollador

Construye y prueba funcionalidades para satisfacer las especificaciones y expectativas del cliente

Participa del diseño

Estima el tiempo y esfuerzo para completar cada funcionalidad

Sirve al equipo como consultor tecnológico

DesarrolladorDesarrollador

TestingTestingRol del Testing

Desarrolla estrategias, planes, y scripts de testeo

Manages the build process Maneja el proceso de construcción

Conduce el testeo para determinar exactamente el estado del desarrollo del producto

Participa en establecer la línea de calidad

Rol de Formación de Usuarios

Actúa como equipo en el usuario final

Actúa como usuario final dentro del equipo

Participa en la definición de los requerimientos de usuario

Participa de las características de diseño

Diseñan y desarrollan sistemas de soporte al usuario

Conduce el proceso de usabilidad

Formaciónde UsuariosFormación

de Usuarios

Gerentede Logística

Gerentede Logística

Rol del Gerente de Logística

Actúa como mediador del equipo hacia las operaciones

Actúa como mediador de las operaciones hacia el equipo

Planea y administra el despliegue del producto

Participa del diseño, centrándose en flexibilidad, portabilidad, y despliegue

Apoya el producto durante la prueba beta

Entrena al personal de operaciones y help desk para la liberación del producto

Alineación de Roles y Objetivos

Rol de Equipo

Gerente de Producto

Gerente de Desarrollo

Desarrollador

Testing

Formación de usuarios

Gerente de logística

Objetivo

Clientes satisfechos

Entregas cumpliendo los requisitos del proyecto

Entregas cumpliendo las especificaciones

Entregar después de resolver todos los temas

Rendimiento mejorado del usuario

Entrega afinada del producto

NO un organigrama tradicional

Testing

Desarrollo

ManagerProyecto

Logística

Desarrollo

AnalistaEducaciónde Usuario

Coordinación con equipos externos

Foco Tecnológico

Foco de NegociosUsuarios Finales

Arquitectos de negocio y

planificadores

Clientes

Arquitectos de TecnologíaY comités de dirección

Operaciones y grupos de soporte

Usuarios Finales

Equipo de Proyecto

Formación de Usuario

Desarrollador

Testing

Gerente deLogistica

Gerentede Producto


Escalando para proyectos pequeños

ProgramManagement

ProgramManagement DevelopmentDevelopment TestingTesting Logistics

ManagementLogistics

ManagementUser

EducationUser

EducationProduct

ManagementProduct

Management

ProgramManagement

ProgramManagement

DevelopmentDevelopment

TestingTesting

LogisticsManagement

LogisticsManagement

UserEducation

UserEducation

ProductManagement

ProductManagement

NoNPosibleP ImprobableI

P

P

P

P

P

P P

P P

P

I

I

II

I

I

I

I

N

N

N

N N

N

N

N

N

N N N

GerenteDe Producto

GerenteDe Producto

Ejemplo: Roles combinados

Gerente deDesarrolloGerente deDesarrollo DesarrolladorDesarrollador

TestingTesting



FormaciónDe UsuariosFormación

De Usuarios

Escalando para proyectos grandes

Dividir los equipos grandes en equipos pequeños, que tienen:

Menor sobrecarga de proceso Menor sobrecarga de

administración Menor sobrecarga de comunicación Implementación más rápida

Crear equipos de funcionalidad-Subequipos multidisciplinarios organizados en torno a grupos de funcionalidades del producto

Crear equipos de función-Subequipos unidisciplinarios organizados en torno a roles funcionales

Ejemplo: Equipos de Funcionalidad


TestingTestingUserEducation

UserEducation

ProgramManagement

ProgramManagement



UserEducation

ProgramManagement

ProgramManagement



UserEducation

ProgramManagement

ProgramManagement

ProgramManagement

ProgramManagement


TestingTesting

LogisticsManagement

LogisticsManagement

UserEducation

UserEducation

ProductManagement

ProductManagement

Equipolíder

Equipo UI

EquipoImpresión

EquipoCentral

Ejemplo: Equipos de Función

Gerente deGrupo de Producto

Evangelizador

RelacionesPúblicas

Marketing

PlanificadorDe Producto

Gerente De Producto

Gerente De Producto

Administración de Riesgos

Riesgo

Definición Diccionario: “Posibilidad de pérdida o

perjuicio”

Webster’s Collegiate Dictionary, 10th edition

Común: Un problema esperando que suceda

Características Inherente en cada proyecto Ni intrínsecamente bueno ni malo No para temer, si para administrar

Documento

de estimación

de riesgos

Top 10

Riesgos Reiterados 3. Plan 5. Control

2. Analizar1. IdentificarDeclaraciónDe Riesgos

4. Track

Proceso de Administración de Riesgos

El entregable de este proceso es el documento de estimación de riesgos

dinámico

El entregable de este proceso es el documento de estimación de riesgos

dinámico

Identificando Riesgos

Descubriendo y reconociendo problemas potenciales dentro del proyecto

Ejemplo: Identificar el fuego como un riesgo potencial en un depósito

Para identificar riesgos efectivamente Usar una estrategia colaborativa Buscar problemas potenciales desde diversas

fuentes Examinar riesgos en dos direcciones

Tópicos potenciales y sus consecuencias probables Consecuencias potenciales y sus causas probables

1. Identificar

Analizando Riesgos

Convertir los datos de riesgos en información para la toma de desiciones

Ejemplo: Comprender que podría causar el fuego en el depósito y cuál sería el costo del daño

Para analizar riesgos efectivamente

Evaluar la probabilidad del riesgo

Evaluar el impacto del riesgo

Calcular la exposición del riesgo

2. Analizar

Diseñando el plan de riesgos

Formular acciones para prevenir y minimizar el riesgo y qué hacer si ocurriera

Ejemplo: Planificar como prevenir el fuego en el depósito y qué hacer si ocurre

Priorizar las desiciones de planificación basadas en la prioridad de los riesgos

Considerar cinco áreas claves Investigación: Conoce lo suficiente de los riesgos? Aceptación: Puede vivir con sus consecuencias? Evasión: Puede evitar el riesgo? Mitigación: Puede reducir la probabilidad? Contingencia: Puede reducir el impacto?

3. Plan

Rastreando Riesgos

Monitorear los riesgos y sus planes de mitigación

Ejemplo: Revisar los 10 riesgos principales de la lista para un cambio de prioridades

Para rastrear riesgos efectivamente Tratar el rastreo de riesgos como un ejercicio

corriente a lo largo de todo el ciclo de vida del proyecto

Seguir los riesgos por cualquier cambio en su condición o consecuencia

Cuantificar el efecto del plan de mitigación Monitorear los disparadores de contingencias

4. Track

Controlando Riesgos

Conducir los resultados del rastreo de riesgos y del proceso como un todo

Ejemplo: Retirar un riesgo que haya sido exitosamente mitigado

Para controlar riesgos efectivamente Adaptar la prioridad de los riesgos según

los cambios Reaccionar a las variaciones del plan Responder a los eventos disparadores Evaluar el proceso de administración de

riesgos

5. Control

Introducción al Modelo de Procesos

Modelos de Procesos

Los modelos del ciclo de vida establecen el orden para las actividades del proyecto

Dos modelos son populares El modelo en cascada El modelo en espiral (o desarrollo rápido de

aplicación)

El modelo de procesos de MSF para desarrollo de aplicaciones combina los beneficios de ambos

Proceso basado en Hitos Procesos flexibles e iterativos

Modelo de Proceso para el desarrollo de Aplicaciones

IENV

SO

G

IN

NI

P LA

NI

GN

ND

EV

LO

PIG

E

N

ST

AB

I LZ

NGI

I

Vision Approved

Vision Approved

Project PlanApproved


Scope Complete

Scope Complete

ReleaseRelease

Proceso Guiado por Hitos

Los hitos son puntos de revisión y sincronización, no puntos de congelamiento

Los hitos permiten al equipo determinar progreso y hacer correcciones en el camino

Los modelos de procesos usan dos tipos de hitos Hitos principales Hitos interinos

Alcanzar un hito principal representa un acuerdo entre el equipo y el cliente de continuar

Las entregas son la evidencia física de que los equipos alcanzaron un hito

Responsabilidades guiadas por hitos

Hito

Visión aprobada

Plan de proyecto

aprobado

Alcance completo

Entrega

Conductor Primario

Gerente de producto


Desarrollador y Formación de usuarios

Testing y Gerente de Logística

Principios de un Proceso Exitoso

Crear documentación actualizada

Utilizar entregas versionadas

Hacer compensaciones del proyecto

Res

ourc

es

Res

ourc

es

FeaturesFeatures

Schedule

Schedule

Matriz de compensaciones del proyecto

ConstrainConstrainOptimizeOptimize AcceptAccept

CronogramaCronograma

CaracterísticasCaracterísticas

RecursosRecursos

Res

ourc

es

Res

ourc

es

FeaturesFeatures

Schedule

Schedule

Hito Visión Aprobada

Visionando

Creando una vista de alto nivel de las metas y restricciones del proyecto

Sirve como una forma temprana de planificación

Ayuda al equipo a encontrar un acuerdo común para diferentes perspectivas

Brinda la base para futuras planificaciones

Captura lo que los clientes y los miembros claves consideran esencial para alcanzar el éxito

Definiendo el alcance

Res

ourc

es

Res

ourc

es

FeaturesFeatures

Schedule

Schedule

VisionandoVisionando

Hito de Visión Aprobada

IENV

SO

G

IN

NI

P LA

NI

GN

N

DE

VL

OPI

GE

N

ST

AB

I LZ

NGI

I



ReleaseRelease

Vision Approved

Vision Approved

Scope Complete

Scope Complete

Indica acuerdo en La razón del

proyecto El producto

esperado Factibilidad del

proyecto Metas y

restricciones del proyecto

Oportunidades y riesgos

Estructura del proyecto

Hitos interinos sugeridos

Borrador del Documento de Estimación de Riesgos

Borrador del Documento Vision

Vision Aprobado

Vision Aprobado

Se ven a nivel de equipo

Dan oportunidad a los miembros de equipo para sincronizar su trabajo

Dan a los miembros del equipo, la oportunidad de evaluar el progreso y el estado actual

Núcleo del equipo formado

Entregables Propósito

Documento Visión

Documento de estimación de riesgos

Documento de estructura del proyecto

Describe lo que se quiere hacer y cómo se piensa hacerlo

Describe los riesgos que conlleva el proyecto

Describe la estructura organizacional del proyecto

Entregables de Visión Aprobado

Dueño

Gerente de Producto



Documento Visión

Documenta lo que se entiende inicialmente por objetivos y restricciones del proyecto

Es el entregable principal de este hito

Da las bases para decisiones de seguir o no seguir

Da un punto de encuentro para el equipo

Guía las decisiones del equipo a un nivel superior

Da una guía para las expectativas de los clientes, usuarios finales y del equipo

Contenido Propósito

Declaración del problema

Declaración de la visión

Concepto de la solución

Perfiles del usuario

Objetivos de negocio

Metas de diseño

Por qué se quiere hacerlo?

Qué se quiere que sea el producto?

Qué se realizará?

Quién utilizará el producto?

Qué se quiere lograr?

Cómo se planea lograrlo?

Contenidos del Documento Visión

Documento de estimación de riesgos

Estimando los riesgos preliminares del proyecto y planificando su administración

Se crea durante el proceso de administración de riesgos

Es la estimación inicial de riesgos del proyecto

Establece las bases para la posterior gestion del riesgo

Provee las bases para organizar cronogramas y tomar decisiones

Documento de estructura del proyecto

Describiendo la estructura organizacional del proyecto y del proceso de gerente de proyecto

Brinda información sobre los miembros del equipo

Incluye información logística del equipo Describe procesos del equipo Actúa como un repositorio de plantillas de

documentación del proyecto

Hito Aprobación del Plan de Proyecto

Importancia de planificar

Costo de reparar defectos por fase

100

80

60

40

20

Envisioning Planning Developing Stabilizing

Definiendo más el alcance

Res

ourc

es

Res

ourc

es

FeaturesFeatures

Schedule

Schedule

PlanificandoPlanificando

Hito Plan de Proyecto Aprobado

IENV

SO

G

IN

NI

P LA

NI

GN

N

DE

VL

OPI

GE

N

L

ST

ABI

ZNG

II

Vision Approved

Vision Approved



Scope Complete

Scope Complete

ReleaseReleaseIndica acuerdo en Estrategia de

compensaciones del proyecto

Riesgos del proyecto Qué se construirá? Cuándo se construirá? Cómo será construido? Quién lo va a

construir?


Borrador de especificación funcional

Plan de Proyecto Aprobado

Plan de Proyecto Aprobado

Borrador de Cronograma de proyecto maestro

Borrador del plan de proyecto maestro

Revisión del proceso de diseño

Diseño LógicoDiseño conceptual

EscenariosEscenariosDiseño Físico

Componentes, interfaz de usuario, y base de datos física

Componentes, interfaz de usuario, y base de datos física

Objetos y servicios, Unterfaz de usuario y base de datos lógica

Objetos y servicios, Unterfaz de usuario y base de datos lógica

Vínculo con la planificación

Plan Proyecto Aprobado

Plan Proyecto Aprobado

Línea base del Diseño Físico

Diseño Conceptual

Diseño Lógico

Diseño Físico

VisionAprobada

VisionAprobada

Línea base del Diseño Lógico

Línea base del Diseño Conceptual

Modelo de aplicación MSF

Serviciosde Negocios

Serviciosde Usuarios

ServiciosDe Datos

Aplicación 1 Aplicación 2

Entregable Propósito

Especificación funcional

Plan de proyecto maestro

Cronograma de proyecto maestro

Documento revisado de estimación de riesgos

Describe qué se va a construir

Describe como será construido

Describe cuándo se construirá

Describe los obstáculos para construir

Entregables para la Aprobación del Plan de Proyectos

Propietario





Principios para cronogramas Precisos

Estimar desde abajo hacia arriba

Tener la mente en una fecha fija de entrega

Calendarizar guiado por los riesgos

Calendarizar para un futuro incierto Sumar un margen de tiempo Utilizar hitos transitorios de desarrollo Utilizar tareas discretas

Indica acuerdo en El conjunto de

característica planeadas

Si dichas características han sido desarrolladas

Línea base de materiales para soportar el rendimiento del usuario

El proceso estabilizado, incluyendo betas y testing

IENV

SO

G

IN

NI

P LA

NI

GN

N

DE

VL

OPI

GE

N

ST

AB

I LZ

NGI

I

Vision Approved

Vision Approved



Scope Complete

Scope Complete

ReleaseRelease



Alcance CompletoAlcance

Completo

Versión Interna n

Versión Interna...

Versión Interna 2

Versión Interna 1

Entregas Internas

LLevar el producto a un estado conocido e incrementalmente construir sobre él

Entrega Interna 1

Entrega Interna 2

6 a 8 semanas

Feature Development

2 a 4 semanas2 a 3 semanas

Testing yestabilización

Tiempo de margen

Test de aceptación

HitoRevisión

Tendencia Defecto-Cero

Consignar el más alto nivel de calidad posible dentro de las restricciones del proyecto

Los miembros del equipo deben comprender el nivel de calidad requerido para su trabajo

El trabajo no está completo hasta que no alcance ese nivel de calidad

La tendencia Defecto-Cero está contenida en

Tareas entregables Hitos

Testing

Asegurarse que las cosas correctas sean hechas correctamente en el tiempo correcto

Descubrir detalles para que puedan direccionarse

Validar que el equipo está haciendo las cosas correctas

Verificar que el equipo las esté haciendo correctamente

Soportar decisiones de negocio y cambios

Mirar el proceso, no solo el producto

Proceso continuo de Testing

DE

VL

O

PIG

E

NS

TA

BI L

ZNG

II



Scope Complete

Scope Complete

ReleaseRelease

Versión Interna 1

Versión Interna 2

Versión Interna...

Test Plan

Especificación de Testing

Completa/Alpha

Betas

Versión Candidata

Versión Golden

Release

Versión Interna n

Versión Cero-Bug

Categorías de Pruebas Testing de aplicación

Intenta probar a fondo cada característica del producto

Intenta probar exhaustivamente el código base del producto

Se usa principalmente durante la fase de desarrollo

Testing de uso Intenta completar satisfactoriamente todos los

escenarios de uso Intenta probar el producto en su ambiente

esperado Se usa principalmente durante la fase de

estabilización

Proceso de Bug Tracking

ResolveDevelopers

CloseTester

Prioritize and Assign

Development Lead

ReportTester

BugRetired

Hito Liberación

Hito Liberación

IENV

SO

G

IN

NI

P LA

NI

GN

N

DE

VL

OPI

GE

N

ST

AB

I LZ

NGI

I

Vision Approved

Vision Approved



Scope Complete

Scope Complete

ReleaseReleaseIndica acuerdo en

Estabilidad de producto y resolución de los bugs conocidos

Aceptación del cliente

Transferencia del dominio para administración y soporte a largo plazo

Cambio en el equipo centrándose en la próxima versión

Testing durante la Fase Estabilización

Es la transición del testing de aplicación al de uso

Involucra tanto el testing interno como el externo El testing de uso interno se focaliza en completar

los escenarios de uso y un amplio testing de configuración

El testing de uso externo se realiza principalmente por medio de las betas

Se aproxima al final del juego


ReleaseRelease

Convergencia de Bug

Versión Cero-Bug

Versión Candidata

Versión Golden

Focalizándose en el lanzamiento

BetaBug Convergence

Zero-Bug Release

Release Candidate

Golden Release

Release0

Bugs Activos

Tiempo

Postmortem

Formalizar el proceso de aprendizaje desde las experiencias pasadas

Son encuentros de revisión post-hitos

Se captura el aprendizaje del proyecto para el desarrollo de los miembros del equipo y la mejora del proceso

Dar por finalizado el proyecto

Son fundamentales para el aprendizaje de la organización

Para más Información Web sites

Microsoft Solutions Framework site at http://www.microsoft.com/MSF

Steve McConnell’s Survival Guide site at http://www.construx.com/survivalguide/home.htm

Libros Dynamics of Software Development, Jim McCarthy Rapid Development, Steve McConnell Software Project Survival Guide, Steve McConnell Debugging the Development Process, Steve

Maguire Microsoft Secrets, Michael A. Cusumano y

Richard W. Selby

Res

ourc

es

Features

Schedule

Project TradeoffsProject Tradeoffs

Versioned ReleasesVersioned Releases

Testing

Developer

ProjectManager

Logistics

Developer

AnalystUser Education

SYSTEM

Databases

User Interface

Services

Data Layer

Business Layer

Presentation Layer

Microsoft Solutions Framework at a Glance

Why use MSF - Typical Root Causes of Failure:

Separation of Goal and Function

Separation of Business and Technology

Lack of Common Language and Process

Failure to Communicate and Act As a Team

Processes That Are Inflexible to Change

Key MSF Principles

Customer-focused projects

Project actions are determined by the goal of solving a particular business problem rather than for the sake of interesting technology. This focus helps to align business and technology, because technology is only being used to support the needs of the business.

User-centric design

This design focus means that the product design is based on how all of the different users need to use the system. This focus aligns what the system does with what it needs to do. If a feature exists in the design, it is to support a use of the product.

NOTE: In MSF terminology, the customer is the individual, group, or organisation paying for the project. The user is the individual, group, or organisation that will use the system or the technology when the project is completed.

Common language and terminology

MSF acts as a baseline for communication. When teams are formed, each member has personal project experience and knowledge of different project methodologies. MSF allows the team to share a simple baseline that each member on the team can agree to and use.

Defined team roles and responsibilities

The MSF Team Model focuses each of its roles on a singular goal that must be accomplished for the project to be successful.

1st Avenue

Plu

m S

tree

t

Ora

ng

e S

tree

t

. .

Smith River

2nd Avenue

3rd Avenue

4th Avenue

. . .. .

S

MSF

.

EW

. .N. .

. .

Methodology

A methodology, like a map, applies specific directions and a specific route to a known destination.

Framework

A framework, like a compass, verifies progress and provides directional guidance when the direction or route changes.

MSF is a framework !

Its models, principles, and practices provide a guide for planning and building business solutions. MSF serves as a useful tool for measuring progress against the original goals.

Potential ProjectsPotential Projects

Enterprise GoalsEnterprise Goals

Enterprisearchitecture

Selects the path

Enterprisearchitecture

Selects the path

Provides theguidance to

get there

Digital Nervous SystemEmbodies business goals of

organisation

Digital Nervous SystemEmbodies business goals of

organisation

Relationship of MSF and the Enterprise Architecture

Retired Risks

Risk Asessment Document

Top 10

Identify

RiskStatement

s

The ongoing deliverable of this process is a living risk assessment document

Control

Track

Analyse

Plan

1122

33

44

55

Briefly, the five steps of the process are:

1. Identify the risk. Bring risks to the surface so teams can deal with them before the risks impact a project.

2. Analyse the risk. Convert risk data into information that a team can use to make decisions.

3. Plan for the risk. Devise plans that will support decision-making and actions taken.

4. Track the risk. Monitor the status of risks and any actions taken to mitigate them.

5. Control the risk. Move risk management into day-to-day project management, which is crucial in ensuring that risk management remains a high-profile activity.

Steps of the MSF Risk Management ProcessBaseline Early

Baseline planning efforts begin as early as possible for an earlier development start

Freeze LateConsider documents as dynamic and subject to change

Functional Specifications

Vision Document

Project Plans

Project Schedule

Risk Management Document

Living Documents

The Six Team Goals for Success

Satisfied Customers

Delivery within Project Constraints

Delivery to Specification

Release After Addressing All Known Issues

Enhanced User Performance

Smooth Deployment and Ongoing Management

Customer

DatabaseCustomer Database

Customer Database

Customer Database

Customer Database

Customer Database

Orders DatabaseOrders

Database

Orders DatabaseOrders

Database

ProductProduct

CustomersCustomers

CustomersCustomers

ProductProduct

OrdersOrders

CustomersCustomers

ProductProduct

Traditional ViewTraditional View Services ViewServices View

Network of Cooperating Services

Application 1 Application 2 Application 3

Stovepiped Services

Application 1 Application 2

MilestoneMilestone

MilestoneMilestone

MilestoneMilestone

MilestoneMilestone

Phase One

Phas

e Fou

r

Phase Three Phas

e Two

Team roles

Product management

Program management

Development

Testing

User education

Logistics management

Goal

Satisfied customers

Delivery within project constraints

Delivery to product specifications

Release after addressing all known issues

Enhanced user performance

Smooth product deployment

MSF PosterMarch 2001