copyright © 2003 by idag ltd. what is msf v3 and why should i, as a manager, developer, deployer,...

Copyright © 2003 by IDAG Ltd.

What is MSF V3And why should I, as a Manager, Developer, Deployer, Integrator or Customer, care about it

Gad J. Meir

IDAG Ltd.

[email protected] © 2003 by IDAG Ltd. and Gad J. Meir. All rights reserved. (Some parts quote Microsoft public materials). This presentation, its workshops, labs and related materials may not be distributed or used in any form or manner without prior written permission by the author(s).


About the Lecturer Gad J. Meir [email protected] IDAG Ltd. B.Sc in Computer Engineering, Technion -

Technical Institute of Israel MCSE, MCSD, MCT and most other Microsoft

Certifications Certified MSF Trainer ,Microsoft International


About IDAG Ltd. Multi-disciplinary Knowledge Mining and Integration Knowledge Measurement and Gap Analysis Knowledge Transfer Consulting, Mentoring, Troubleshooting Founded in 1983 Establishment of Microsoft University IL (1992) Project management mentoring, using Microsoft Solution

Framework (MSF) Microsoft Solution Provider At least 25% of company time is dedicated to practical projects

in order to acquire real-world experience


… Why don’t you make mistakes ? Because I have a lot of experience ! How did you get your experience ? I did a lot of mistakes !!!


Project Failure Rates

Based on Application Development Projects, but Similar Numbers are in Deployment and Integration Projects

Challenged

Succeeded

Failed 28%28%46%46%

26%26%


Success Hasn’t Come Easily

2000

1998

1995

1994

28%23% 49%

26%28% 46%

27%40% 33%

16%31% 53%

This chart depicts the outcome of the 30,000 application projects in large, medium,and small cross-industry U.S. companies tested by The Standish Group since 1994.

Source: The Standish Group International, Extreme Chaos, The Standish Group International, Inc., 2000

SucceededChallengedFailed


What exactly do you mean by Challenged ?

Challenged is the nice positive American way to tell you that you fucked the project Average cost overrun: 189% Projects re-started: 94% Time overrun: 222% Functionality delivered on average: 61%

The truth is If a project is delivered on time, within budget and

exactly according to the specifications, it is a miracle (miracle := 25%)


“When projects fail, it’s rarely technical.”

Jim Johnson, The Standish Group

Root Causes of Failure

Separation of goal and function The specification does not describe the real problem that the

customer wants to solve

Separation of business and technology The technology should serve the business and not become the

reason for the change

Lack of common language and process The development team doesn’t understand the business and

interprets the specification wrong The process of the project is not clear to the customer and the

team

Failure to communicate and act as a team The team is not a team but a group of individuals pushing to

opposite directions

Processes that are inflexible to change When a change is needed in the specification, it can’t be done

without actually restarting the project


The problem is not new and the solutions are not new

Use good methodology, PMI, CRM, BPR, EAI (Google search returns over 135,000 sites dealing with project management methodologies all of them promise the crystal ball)

Learn the subject of project management Be an expert on the subject meters (anything connected to the

project subject) Learn how to guide and lead people Learn Politics and Human resource management… Be a good psychologist, social worker, emphatic…


The practical problem of a project leader It’s takes a Huge amount of Information and

Knowledge to master and you don’t have time It’s easy to get lost in the translation of theory to

practice and you don’t have enough experience You have to make a many decisions under time

pressure and without enough information Methodology does not help a lot in day to day

practical decisions You need something light, easy to use, simple, to

show you the way when you are In doubt You need a Compass That’s exactly MSF


Framework: Supplementing Methodologies

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

.

.. .

The Methodology is the map with the instructions how to get there

The framework is the compass that is always pointing to the target and show you the direction whenever you are lost


Origins of MSF

Microsoft Worldwide Products Groups

Microsoft Worldwide Products Groups

MicrosoftInformationTechnology

MicrosoftInformationTechnology

Microsoft Consulting

Services

Microsoft Consulting

Services

Microsoft Partners

Microsoft Partners

Best PracticesBest Practices Microsoft Solutions FrameworkMicrosoft Solutions Framework

Concepts

Principles

Models

Best Practices

• Development AND Deployment, not just Development

• Microsoft has a lot of experience in successful and failed projects and there is a lot to learn from them


Setting Expectations NOT

MSF does not solve all your problems MSF does not guarantee your project’s success

YES MSF increases your success percentage MSF tells you VERY early in the project life cycle

that you are going to fail (You can stop the project before it costs too much)

MSF is easy to learn and implement


Setting Expectations II

I am not going to teach all MSF principles here and now it is a 4 days workshop

I am going to show some of the principles and describe the logic behind them

MSF is really just common sense pills to make your project healthier

You don’t have to take it all at once, sometimes one good idea is enough to save you when you are alone in the dark


RiskManagement

Discipline

ProcessModel

TeamModel

ProjectManagement

Discipline

ReadinessManagement

Discipline

MSF Models and DisciplinesModels

Disciplines


Where MSF Fits in the IT Life Cycle

Microsoft Operations Framework

Microsoft Solutions Framework

Operate

Dep

loy

Build

Pla

n


MSF Process Model Is an Iterative Approach

Time

Fu

nct

ion

alit

yMinimize risks by breaking large projects into multiple versions

Version 1

Version 2

Version 3


Why Versioned Releases You can’t effectively manage a project if it is longer than 6

months Most projects are longer then 6 months By deciding on versioned releases you can decide which subset

of the problem is fitted to the time The customer must prioritize the features The customer has something in hand earlier Mistakes discovered early are cheaper to fix Establish your credibility Give you flexibility in case of pressure

“We can move this feature to the next release” Enable you to better fit the solution to your precise customer’s

needs You respond faster to changes The delta between the specification and the real world is smaller


Making Project Trade-offs

Res

ourc

es

Res

ourc

es

FeaturesFeaturesS

chedule

Schedule


Why use Project Trade-offs?

Because you will have to It never goes according to plan Why bury your head in the sand? Why not discuss it with your customer? You will have to do it anyway so why wait for

the first crisis How can we do all this ??? …


Project Trade-off Matrix

ConstrainConstrainOptimizeOptimize AcceptAccept

ScheduleSchedule

FeaturesFeatures

ResourcesResources

Res

ourc

es

Res

ourc

es

FeaturesFeatures

Schedule

Schedule

Help your customer help you

• Constrain – do not change, this is a constant

• Optimize – try to minimize this

• Accept – well, I’ll except any changes on this


MSF Process Model Phases and Milestones

Project Plans Approved

Scope Complete

Release ReadinessApproved

DeploymentComplete

Vision/Scope Approved

MSF


Milestone-Driven Process Milestones are review and synchronization points,

not freeze points Milestones enable the team (and customer) to assess

progress and make mid-course corrections The process model uses two sorts of milestones

Major milestones, end of logical quarter Interim milestones, in the logical quarter

Achieving interim milestone represents team agreement on position in the process

Achieving a major milestone represents team and customer agreement on position in the process


Milestones are based on Deliverables

Deliverables are physical evidence (documents)

Deliverables are signed by the team (and sometimes the customer)

A signed (or agreed) deliverable signal that the team has reached a milestone


Milestone MSF Role Cluster

Vision/scope approved Product management

Project plans approved Program management

Scope complete DevelopmentUser experience

Release readiness approved TestingRelease management

Deployment complete Release management

Different Roles Drive Different Phases


The process milestones based Approach

Segment the Project into milestonesHelp organize the teamFacilitate communication in the teamFacilitate communication with the customerYOU NEVER GET BLINDEDYOU ALWAYS KNOW WHERE YOU ARE


Risk Management Model Risk is a problem waiting to happen If you don’t analyze it, and prepare for it,

you'll get it in you face You should anticipate risks, mitigate risks

and prepare contingency plans for risks Because some of those risks are going to

happen (it is just statistics) Risk analyzing is integral, living, changing,

part of any project


Analyze andPrioritize

Analyze andPrioritize

MasterRisk List

Top nRisks

Plan andSchedulePlan andSchedule

Identity

RiskStatement

ControlControl

The MSF Risk Management Process

LearnLearnRisk

Knowledge Base,Concepts,

and Processes

Track andReport

Track andReport

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


Goals for a Successful Project Satisfied customers

The customer pays you, politics, seals person

Delivery within project constraints Watch the budget, deal with crises, mitigate

Delivery to specifications that are based on user requirements Write the code, take development decisions.

Release after addressing all known issues Test the code, specification, everything.

Enhanced user performance Most of the time, the customer doesn’t use the project. It’s the user of the system that

make it a success or failure. (UI design, Graphics, Cognitive approach)

Smooth deployment and ongoing management Packing, buying equipment, printing, delivering, electricity, water, air conditioning,

logistics, etc’…


Overall success requires success in each goal Any of them may fail the project

It is straight from the root, because of the failure we discussed earlier Each goal must be equally valued Each goal requires disciplines that are focused on

that goal Each goal needs different qualifications You need them all You can’t learn everything, you cant do everything,

you cant be everyone… So….

Understanding the Goals


MSF Team Model

Communication

Delivering the solution within project constraints

Satisfied customers

Enhanced user effectiveness

Smooth deployment and ongoing operations

Approval for release only after all quality issues are identified and addressed

Building to specification

DevelopmentDevelopment

TestTest

Release Management

Release Management

UserExperience

UserExperience

ProductManagement

ProductManagement

Program Management

Program Management


Team of Peers Is a team whose members relate as equals Has specific roles and responsibilities for each

member Empowers individuals in their roles Holds members accountable for the success of their

roles Drives consensus-based decision-making Gives all team members a stake in the success of the

project


Principles of a Successful Team

Team of Peers Shared Product Vision Product Mindset Zero-Defect Mindset Customer-Focused Mindset Willingness to Learn


Scaling for Small ProjectsProgram

ManagementProgram

Management DevelopmentDevelopment TestingTesting LogisticsManagement

LogisticsManagement

UserEducation

UserEducation

ProductManagement

ProductManagement

ProgramManagement

ProgramManagement


TestingTesting

LogisticsManagement

LogisticsManagement

UserEducation

UserEducation

ProductManagement

ProductManagement

NoNPossibleP UnlikelyU

P

P

P

P

P

P P

P P

P

U

U

UU

U

U

U

U

N

N

N

N N

N

N

N

N

N N N


UserExperience

UserExperience

ProductManagement

ProductManagement

TestTest

ProgramManagement

ProgramManagement

ReleaseManagement

ReleaseManagement


Example: Small TeamsSmall team, combined roles


Scaling for Large Projects Divide large teams into smaller teams, which

have Lower process overhead Lower management overhead Lower communication overhead Faster implementation

Create feature teams—multidisciplinary subteams organized around product feature sets

Create function teams—unidisciplinary subteams organized by functional roles


Feature Teams

Multidisciplinary sub-teams organized around product feature sets or created to focus on a particular capability

ProgramManagement

ProgramManagement

ReleaseManagement

ReleaseManagement

ProductManagement

ProductManagement

UserExperience

UserExperience


TestTest

Lead Team

DesktopFeatureTeam

ProgramManagement

ProgramManagement

UserExperience

UserExperience


TestTest

File and Print FeatureTeam

ProgramManagement

ProgramManagement

UserExperience

UserExperience


TestTest

MessagingFeatureTeam

ProgramManagement

ProgramManagement

UserExperience

UserExperience


TestTest


Example: Function Team

Group ProductManagement

Evangelism

PublicRelations

Marketing

Product Planning

ProductManagement

ProductManagement


MSF Team Role Clusters and Their Functional Areas

Business valueMarketingCustomer advocacyProduct planning

Project managementSolution architectureProcess assuranceAdministrative services

Technology consultingImplementation architecture and designApplication developmentInfrastructure development

Test planningTest engineeringTest reporting

InfrastructureSupportOperationsLogisticsCommercial release management

AccessibilityInternationalizationUser advocacyTraining/support materialUsability research and testingUser interface design


TestTest

Release Management

Release Management

UserExperience

UserExperience

ProductManagement

ProductManagement

Program Management

Program Management


MSF Readiness Discipline

KnowledgeSkills

Abilities

AssessAssess

ChangeChange

DefineDefine

EvaluateEvaluate


Courses 1846: Microsoft Solutions Framework Essentials 1737: Microsoft Operations Framework Essentials 1585: Gathering and Analyzing Business Requirements 1608: Designing Business Solutions 1609: Designing Data Services and Data Models

All Syllabuses are available on Microsoft’s web site


For More InformationWeb 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

Books 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 and Richard W.

Selby


Call to Action Have management commitment

If you need help call me Or Eran Kolber for a 1 hour presentation to management

Find a Pilot project and assemble a team Train the team using certified trainer

4 days workshop based on 1846 Use one of the trainers or both as a consultant to mentor the

team Just to verify that you are doing it right There are a lot of gray areas when you try to do it for the first time

If the project succeeds, this team will be the base to build the other teams

If the project fails, analyze the cause of failure and decide if you want to try again

Remember, it is statistics and not a full guarantee


Questions?


Copyright © 2003 by IDAG Ltd. and Gad J. Meir. All rights reserved. (Some parts quote Microsoft public materials). This presentation, its workshops, labs and related materials may not be distributed or used in any form or manner without prior written permission by the author(s).

copyright © 2003 by idag ltd. what is msf v3 and why should i, as a manager, developer, deployer,...

Documents

meir idag

microsoft international

integration projects

standish group international

application projects

team failure

realworld experience

practical projects