Session partially based on
excellent materials for new
MSF course 1846
DEV238
A-to-Z of MSF v3 (Microsoft
Solutions Framework)
Rafal Lukawiecki
rafal@projectbotticelli.co.uk
www.projectbotticelli.co.uk
Strategic Consultant
Project Botticelli Ltd
2
My Objective
Relate to key reasons why projects fail
Convince you MSF can help solve many
project issues
Explain the innovation in MSF v3
Give you tips on how to start using MSF
Connect MSF to MOF
3
Agenda
What is MSF v3
Statistics
The Useful Bits of MSF v3
Implementing MSF
And there will be a video on an MSF case
study: UK eGovernment
4
MSF
Microsoft Solutions Framework
Established in 1991, last major revisions in
1998 and January 2003 (v3).
Related to MOF, Microsoft Operational
Framework
Which concentrates on the management of
IT infrastructure
5
Lifecycle of IT
Microsoft Solutions Framework
Microsoft Operations Framework
6
Project Failure Rates
2000
1998
Failed
Challenged
Succeeded
23%
49%
28%
28%
1995
1994
46%
40%
31%
26%
33%
53%
27%
16%
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
7
Does it Work?
Yes, as long as you chose the right bits of
MSF for your project
High-profile projects that used MSF
www.nasdaq.com and www.marriott.com
(Aris Corp, now Ciber, www.ciber.co.uk)
Visual Studio, Windows 2003, Windows XP
8
What’s a Framework?
Unlike a methodology, a framework is a
set of “tools” or best practices to choose
from
Is that good?
Yes, because it is easier to apply, more
flexible and less restrictive
Yes, because it combines well with
methodologies (RUP, Prince 2, etc.)
No, because you have to make choices 
9
Is It For Everyone?
Some parts of MSF will work for every
project, but in general, most of MSF
works for larger projects
How small is large enough?
3-12 months (best of all 4-6) and with a
team of at least 3 (best of all 7-11)
Or more, by using built-in team scaling
tools, such as Feature Teams
10
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
Solution?
A good and tested framework!
“When projects fail, it’s
rarely technical.”
Jim Johnson, The Standish Group
Average cost overrun:
189%
Time overrun:
222%
Projects re-started:
94%
Functionality delivered on
average:
61%
Standish Group
11
Key MSF Components
Models
Team
Process
Model
Model
Disciplines
Project
Management
Discipline
Risk
Readiness
Management
Discipline
Management
Discipline
12
Key MSF Components
13
A Team of Peers
Delivering the solution
within project constraints
Satisfied
customers
Program
Management
Product
Management
Building to
specification
Development
Communication
User
Experience
Enhanced user
effectiveness
Test
Release
Management
Smooth deployment and
ongoing operations
Approval for release only
after all quality issues are
identified and addressed
14
Scaling The Model
You can combine some roles to teams as small
as 3 people
Do not combine some (like Product and Program
Manager, or anything with Developer)
You can scale it to 10, 100s and 1000s by using
two methods:
Functional Teams (many people for one role)
Feature Teams (sub-teams for each feature)
15
Project Management
Full alignement with PMIBOK (Project
Management Institute Body of
Knowledge)
Remember: MSF is not a project
management method, but a project
framework that needs some project
management – PMI is great for that
16
Project Management
Team leads for each role own the responsibilities corresponding to
the listed knowledge areas
Team Leads
Program Management
Product Management
Development
Test
User Experience
Release Management
at overall project level
at sub-team level
17
MSF Process Model
Deployment
Complete
Release Readiness
Approved
Vision/Scope
Approved
MSF
Scope
Complete
Project Plans
Approved
18
Daily Build
Building the product in
an executable form on a
daily basis
A public daily build is
A strong indicator that a team is
functional
A way to make the product and its
progress visible
The heartbeat of the development
process
19
Internal Releases
Daily builds lead to internal (alpha
releases)
Internal
Release
Feature
n
Development
Daily Builds
Testing and
Stabilizing
Internal
Buffer Release
n+1
Time
20
Can I Really Build Every Day?
On a typical 4-6 month project, you will
not be ready for a daily build for the first 35 days at the most
Then you can!
21
How Does Daily Build Work?
A
A
A → A’
B
C
B
A’
B
C’
B
A’
B, B’
C’
A
B → B’
C
C
C
A
B
C → C’
A’
B
C’
A’’
From A’
→
B’’
From B
and B’
C’’
From C’
Day 1 → BVT → Day 2 → BVT → Day 3
22
Tips for Daily Build
Use source-code control system (such as Microsoft
Visual Source Safe, Rational ClearCase etc.)
Each developer works locally, i.e. all code and
executables on every station
Every day code is collected, built and published and
every morning developers download the newest build
Designate quality levels (BVT, TST, IDW, IDS, IDC –
Microsoft “speak”)
Automate it all (batch files etc.)
Developing them is an ongoing activity that will be complete
when your first project completes
Use Visual Studio.NET 2003 with MSDN Universal – there is
new automation for daily build in it!
23
Ongoing Process of Testing
Release
Golden Release/RTM
Release Candidates
Release
Readiness
Zero-Bug Bounce
Test Specification
Complete/Alpha
Scope
Complete
Internal Release n (Alpha, Pilot)
Product Stability
Betas
Internal Release ...
Internal Release 2
Project Plan
Approved
Internal Release 1
Test Plan
24
Risk Management Process
1. Identify
Retired
Risks
Risk
Statements
5. Control
2. Analyze
Risk
Assessment
Document
Top 10
4. Track
3. Plan
25
Design Process Overview
Conceptual Design
Scenarios
Logical Design
Objects and Services,
User Interface, and
Logical Database
Physical Design
Components,
User Interface, and
Physical Database
26
Relationship to Planning
Vision
Approved
Project Plan
Approved
Conceptual Design
Logical Design
Physical Design
Conceptual
Design Baseline
Logical Design
Baseline
Physical Design
Baseline
27
video
Does It Work?
UK eGovernment
Case Study
28
Implementing MSF
29
Getting MSF in 7 Steps
1.
2.
3.
4.
5.
6.
7.
Select a group of senior decision makers and present
them an executive summary (e.g. this presentation and
Q&A)
Selects a pilot development group and project (6-10
people, 4-6 months, new project)
Train on MSF Essentials MOC #1846 course
Optionally, appoint a consultant to provide “health
feedback”
Executes the project successfully
Revise and customise MSF if needed
Optionally, plan and restructure the organisation if the
success is worth repeating
30
What If My And Customer’s
Teams Are Mixed?
Most partners have a “fun” time winning and running
these projects
Teach the customer MSF before the project starts as a
“closed” (private) course
They will trust you more
They will be more likely to succeed by understanding how you
work
You are much more likely to win the project
Make sure you have someone responsible for all roles –
do not “split the team” (i.e. you are Program Manager
and customer provides a Product Manager)
Conflict of interests
31
Summary
Projects fail for non-techy reasons
A framework such as MSF fixes that
problem
You don’t have to use all of MSF at once
If you use some bits you increase your
chance of succeeding
32
Resources & Actions
Visit www.microsoft.com/msf
Attend course “MSF Essentials” MOC #1846
Pass the “MSF Practitioner” Prometric test
Read:
“Dynamics of Software Development” by Jim
McCarty, Microsoft Press
I’ll eventually have a book out on this subject… 
34
evaluations
35
© 2003 Microsoft Corporation & Project Botticelli Ltd. All rights reserved. This presentation is for informational
purposes only. MICROSOFT AND PROJECT BOTTICELLI MAKE NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.