DEV238
A-to-Z of MSF v3 (Microsoft Solutions Framework)Rafal Lukawieckirafal@projectbotticelli.co.ukwww.projectbotticelli.co.uk
Strategic ConsultantProject Botticelli Ltd
Session partially based on excellent materials for new
MSF course 1846
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 FrameworkEstablished 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 Operations Framework
Microsoft Solutions Framework
Operate
Dep
loy
Build
Pla
n
6
Project Failure Rates
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
7
Does it Work?
Yes, as long as you chose the right bits of MSF for your project
High-profile projects that used MSFwww.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
“When projects fail, it’s rarely technical.”
Jim Johnson, The Standish Group
Root Causes of Failure
Separation of goal and functionSeparation of business and technologyLack of common language and processFailure to communicate and act as a teamProcesses that are inflexible to changeSolution?
A good and tested framework!
Average cost overrun: 189%Time overrun: 222%Projects re-started: 94%
Functionality delivered on average: 61%
Standish Group
11
Key MSF Components
RiskManagement
Discipline
ProcessModel
TeamModel
ProjectManagement
Discipline
ReadinessManagement
Discipline
Models
Disciplines
12
Key MSF Components
13
A Team of Peers
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
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 ManagementTeam 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
Quality M
anagement
Procu
rement M
anagement
Risk M
anagement
Communicatio
ns Management
Human Reso
urce M
anagement
Cost Management
Time M
anagement
Scope M
anagement
Integratio
n Management
at overall project level at sub-team level
17
MSF Process Model
Project Plans Approved
Scope Complete
Release ReadinessApproved
DeploymentComplete
Vision/Scope Approved
MSF
18
Daily Build
Building the product in an executable form on a daily basis
A public daily build isA strong indicator that a team is functionalA way to make the product and its progress visibleThe heartbeat of the development process
19
Internal Releases
Daily builds lead to internal (alpha releases)
InternalRelease
n
InternalRelease
n + 1Testing andStabilizing
BufferTime
FeatureDevelopment
Daily Builds
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 3-5 days at the most
Then you can!
21
How Does Daily Build Work?
AA → A’BC
BAB → B’C
CABC → C’
AA’BC’
BA’B, B’C’
CA’BC’
A’’From A’
B’’From B and B’
C’’From C’
→
Day 1 Day 2 Day 3BVT BVT→ → → →
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 stationEvery day code is collected, built and published and every morning developers download the newest buildDesignate 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 completesUse Visual Studio.NET 2003 with MSDN Universal – there is new automation for daily build in it!
23
ReleaseReadinessRelease
Readiness
Ongoing Process of Testing
DE
VL
O
PIG
E
NS
TA
BI L
ZNG
II
Project PlanApproved
Project PlanApproved
Scope Complete
Scope Complete
Internal Release 1
Internal Release 2
Internal Release ...
Test Plan
Test Specification Complete/Alpha
Betas
Release Candidates
Golden Release/RTM
Release
Internal Release n (Alpha, Pilot)
Zero-Bug BounceP
rod
uc
t Sta
bility
24
Retired Risks
Risk Assessment Document
Top 10
3. Plan 5. Control
2. Analyze1. IdentifyRisk
Statements
4. Track
Risk Management Process
25
Design Process Overview
Logical DesignConceptual Design
ScenariosScenariosPhysical Design
Components,User Interface, and Physical Database
Components,User Interface, and Physical Database
Objects and Services,User Interface, and Logical Database
Objects and Services,User Interface, and Logical Database
26
Relationship to Planning
Project PlanApproved
Project PlanApproved
Physical Design Baseline
Conceptual Design
Logical Design
Physical Design
VisionApproved
VisionApproved
Logical Design Baseline
Conceptual Design Baseline
27
videovideo
Does It Work?UK eGovernment Case Study
28
Implementing MSF
29
Getting MSF in 7 Steps
1. Select a group of senior decision makers and present them an executive summary (e.g. this presentation and Q&A)
2. Selects a pilot development group and project (6-10 people, 4-6 months, new project)
3. Train on MSF Essentials MOC #1846 course4. Optionally, appoint a consultant to provide “health
feedback”5. Executes the project successfully6. Revise and customise MSF if needed7. 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 projectsTeach the customer MSF before the project starts as a “closed” (private) course
They will trust you moreThey will be more likely to succeed by understanding how you workYou 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
evaluationsevaluations
35
© 2003 Microsoft Corporation & Project Botticelli Ltd. All rights reserved. This presentation is for informational © 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.purposes only. MICROSOFT AND PROJECT BOTTICELLI MAKE NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.
