Upload
lorraine-white
View
254
Download
3
Tags:
Embed Size (px)
Citation preview
2
Agenda
Introduction MSF Team Model MSF Process Model MSF Project Management Discipline MSF Risk Management Discipline MSF Readiness Management Discipline
3
What Is the MSF
Guidance to help organizations be more successful delivering IT Solutions
A collection of principles, processes and best practices grouped into “Models & Disciplines”
Framework for project management Team Model Process Model Risk Management
A “Framework” Can be used in place of a method Integrates well with existing processes and procedures
Can be combined with methods MSF is a platform for reducing risk Pieces of the framework are often useful no matter the situation… look for
the best practices Use to identify gaps in existing processes or methods
4
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
(Agile,RUP, Prince 2...) No, because you have to make choices
5
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
.
.. .A methodology applies specific directions to a known destination
A framework, like a compass, verifies progress and provides directional guidance
A framework is a methodology partner!
6
One IT Lifecycle – Multiple Perspectives
MicrosoftSolutions
Framework
CommonDisciplines
&Shared
Responsibility
MicrosoftOperationsFramework
EnterprisePerspective
SystemsPerspective
Pla
n
Build
Dep
loy
Operate
7
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
8
MSF & MOF
Microsoft Solutions Framework Established in 1991, last major revisions in 1999 , 2003 Visual Studio 2005 Team System Software Development and Infrastructure Deployment
Microsoft Operations Framework Established in 1999 based on mature ITIL (IT Infrastructure
Library) Updated December 2002 Concentrates on management of IT operations
MSF is a vehicle for delivering Microsoft’s contributions to the software development community
Microsoft almost does not market MSF and they are not selling it, instead, they focus on making money using MSF
9
A Brief History
1994 1995 1997 1999 2002 1994 1995 1997 1999 2002 2005-06 2005-06
MS
F O
fferi
ng
MS
F O
fferi
ng
MSF MSF v1v1
21 Rules21 Rules
““DynamicDynamics”s”
SolutionsSolutionsDevDevDisciplineDiscipline(SDD)(SDD)
MSF v2MSF v2Principles of …Principles of …App Dev (PAD)App Dev (PAD)Infra Deploy (PID)Infra Deploy (PID)Ent Arch (PEA)Ent Arch (PEA)Comp Des (PCD)Comp Des (PCD)
MSF MSF v2.5v2.5
MSF v3MSF v3
EssentialsEssentials+ Exam+ Exam
CoreCoreAgileAgileCMMICMMI……
MSF v4MSF v4
10
MSFv4 Family TreeFrameworkFramework
MethodologyMethodology
MSF for MSF for Agile Agile
Software Software DevelopmeDevelopme
ntnt
MSF for MSF for CMMICMMI®®
Process Process ImprovemenImprovemen
tt
InfrastructInfrastructureure
MSFv4 CoreMSFv4 Core
Application Application DevelopmeDevelopme
ntnt
DisciplineDiscipline
ProductProduct(instantiated)(instantiated)
FamilyFamily
11
Content RelationshipMSFv4 MSFv4 “Core”“Core” DisciplineDiscipline
InfrastructurInfrastructuree
MSF for Agile MSF for Agile Software Software
DevelopmentDevelopment
MSF for CMMIMSF for CMMI®® Process Process
ImprovementImprovementProductProduct
Application Application DevelopmentDevelopment FamilyFamily
MSF v4MSF v4
MSF v3MSF v3
InfrastructureInfrastructureCMMICMMI
AgileAgile
12
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
MSF is an “agile” process
13
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
14
Where MSF Fits in the IT Life Cycle
Microsoft Operations Framework
Microsoft Solutions Framework
Operate
Dep
loy
Build
Pla
n
15
RiskManagement
Discipline
ProcessModel
TeamModel
ProjectManagement
Discipline
ReadinessManagement
Discipline
Key Parts of MSFModels
Disciplines
Getting Results Minimize Surprises Anticipate & Grow Skills
17
Agenda
Introduction MSF Team Model MSF Process Model MSF Project Management Discipline MSF Risk Management Discipline MSF Readiness Management Discipline
18
Team Goals for Success Satisfied customers Delivery within project constraints Delivery to specifications that are
based on user requirements Release after addressing all known issues Enhanced user performance Smooth deployment and ongoing management
19
MSF Team Model
ProgramManagement
ProgramManagement
DevelopmentDevelopment
TestingTesting
ReleaseManagement
ReleaseManagement
UserExperience
UserExperience
ProductManagement
ProductManagement
Team of Peers
20
Why These 6 Roles? Key goals need dedicated equally valued roles:
Customer Satisfaction: Product Manager Project delivered within Project Constraints: Program Manager Design and Implementation Based on Specification: Development All Issues Known and Addressed: Testing Users Performing Better: User Experience Deployment, Admin, and Support: Release Management
23
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
Program Management
Development
Test
Release Management
User Experience
Product Management
24
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
25
Product Manager
Acts as customer advocate to the Team Drives shared project vision/scope Manages customer requirements definition Develops and maintains business case Manages customer expectations Drives features vs. schedule vs. resources tradeoff
decisions Manages marketing, evangelizing and public relations Develops, maintains, and executes the communications
plan
26
Program Manager
Drives development process to ship product on time Manages product specification—primary project architect Facilitates communication and negotiation within the team Maintains the project schedule and reports project status Drives implementation of critical trade-off decisions Develops, maintains, and executes the project master plan
and schedule Drives and manages risk assessment and risk management
27
Development Role
Specifies the features of physical design Estimates time and effort to complete each feature Builds or supervises building of features Prepares product for deployment Provides technology subject matter expertise to the team
32
Principles of a Successful Team
Shared project vision Product mindset Zero-defect mindset Customer-focused mindset Willingness to learn
33
Fixed-Ship-Date Mindset A fixed-ship date mindset means that a team treats its projected ship date
as unchangeable Essentially the schedule side of the triangle is considered fixed The team cannot use this side of the triangle for making corrective decisions unless no other
option is available. Forces creativity by requiring the team to implement features in as
timely a manner as possible and removing the option of delaying the ship date
Prioritizes tasks according to importance -- If the team needs to drop features in order to make the ship date, it delivers those most important to the customer)
Empowers the team by providing an effective decision-making tool -- The team makes decisions on the basis of how they will affect the team’s ability to deliver on the fixed ship date.
Provides a motivational goal for the team “There’s a thousand different variables that go into shipping a product, the feature
sets, the people working on it, how long they’re working, a bunch of stuff. All we’re trying to do is fix one of them, just one. Of all the thousand variables, let’s just fix one variable and let’s vary the other 999 variables. When you fix the ship date, you force creativity, you force decisions.”
35
Combining Roles for Small Projects
ProgramManagement
ProgramManagement DevelopmentDevelopment TestTest Release
ManagementRelease
ManagementUser
ExperienceUser
ExperienceProduct
ManagementProduct
Management
ProgramManagement
ProgramManagement
DevelopmentDevelopment
TestTest
ReleaseManagement
ReleaseManagement
ProductManagement
ProductManagement
P
P
P
P
P
P P
P P
P
P
P
P
P
P
P P
P P
P
U
U
UU
U
U
U
U
U
U
UU
U
U
U
U
N
N
N
N N
N
N
N
N
N N NN
N
N
N N
N
N
N
N
N N N
UserExperience
UserExperience
P = Possible U = Unlikely N = Not Recommended
36
ProductManagement
ProductManagement
Teams: Scaling Down
ProgramManagement
ProgramManagement DevelopmentDevelopment
TestingTesting
ReleaseManagement
ReleaseManagement
UserExperience
UserExperience
37
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
38
Feature TeamsMultidisciplinary sub-teams organized around product feature sets or created to focus on a particular capability
ProgramManagement
ProgramManagement
ReleaseManagement
ReleaseManagement
ProductManagement
ProductManagement
UserExperience
UserExperience
DevelopmentDevelopment
TestTest
Lead Team
DesktopFeatureTeam
ProgramManagement
ProgramManagement
UserExperience
UserExperience
DevelopmentDevelopment
TestTest
File and Print FeatureTeam
ProgramManagement
ProgramManagement
UserExperience
UserExperience
DevelopmentDevelopment
TestTest
MessagingFeatureTeam
ProgramManagement
ProgramManagement
UserExperience
UserExperience
DevelopmentDevelopment
TestTest
39
Example: Function Team
Group ProductManagement
Evangelism
PublicRelations
Marketing
Product Planning
ProductManagement
ProductManagement
41
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
DevelopmentDevelopment
TestTest
Release Management
Release Management
UserExperience
UserExperience
ProductManagement
ProductManagement
Program Management
Program Management
42
Agenda
Introduction MSF Team Model MSF Process Model MSF Project Management Discipline MSF Risk Management Discipline MSF Readiness Management Discipline
43
MSF Process Model
Project Plans Approved
Scope Complete
Release ReadinessApproved
DeploymentComplete
Vision/Scope Approved
MSF
44
MSF Process Principles and Practices Using versioned releases Scheduling for an uncertain future Managing trade-offs Maintaining a fixed-ship-date mindset Managing risk Breaking large projects into manageable parts Driving process with milestones Using bottom-up and milestone-based estimating Performing daily builds Conducting post-project reviews
45
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
46
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
47
Envisioning Phase
Deliverables Vision/scope
document Project structure
document Initial risk
assessment document
50
Planning Phase
Deliverables: Functional
specifications Master project
plan Master project
schedule
53
Developing Phase
Deliverables: Solution code Build images Training materials Documentation
Deployment processes Operational procedures Support and troubleshooting
Marketing materials Updated master plan and schedule
58
Stabilizing Phase
Deliverables: Pilot review Release-ready versions:
Source code andexecutables
Scripts and installation documentation
End-user help and training materials
Operations documentation Release notes
Testing and bug reports Project documents
61
MSF
Testing the SolutionTesting is part of the build cycle, not a standalone activity
Release ReadinessApproved
ScopeComplete
Project PlansApproved
63
Deploying Phase
Deliverables Operations and
support informationsystems
Repository of allversions of docs,load sets, configs,scripts, and code
Project close-out report
65
MSF Phases and Milestones
Project Plans Approved
Scope Complete
Release ReadinessApproved
DeploymentComplete
Vision/Scope Approved
Pilot Complete
Pre-Production Testing Complete
Release Candidates
User Acceptance Testing Complete
Zero Bug Bounce
Bug Convergence
Technology Validation Complete
Functional Specifications Baselined
Master Project Plan Baselined
Master Project Schedule Baselined
Development/Test Environment Set Up
Deployment Stabilized
Site Deployments Complete
Core Technology Deployed
Core Team Organized
Vision/Scope Baselined
Proof of Concept CompleteInternal Release 1
Internal Release 2Internal Release n
66
Standard MSF Deliverables
I. Envisioning: “Vision Approved” Milestone Vision document Risk assessment Project structure document
II. Planning: “Scope Complete” Milestone Functional specification Risk assessment Project schedule Operation and support information systems
Procedures and processes Knowledge base, reports, logbooks
III. Developing: “Scope Complete” Milestone Frozen functional specification Risk management plan Source code and executables Performance support elements Test specification and test cases Master project plan and master project schedule
IV. Stabilizing: “Release” Milestone Golden release Release notes Performance support elements Test results and testing tools Source code and executables Project documents Milestone review
V. Deploying: “Deployment Complete” Milestone Documentation repository for all versions of
documents, load sets, and code developed during the project.
Project close-out report Final versions of all project documents Customer/user satisfaction data Definition of next steps
67
Envisioning Phase Planning Phase Developing Phase Stabilizing Phase Deploying Phase Overall goals Identify customer requirements Vision / scope document
Conceptual design Business requirements
analysis Communications plan
Customer expectations Communications plan execution
Launch planning
Customer feedback, assessment, signoff
Design goals Solution concept Project structure
Conceptual and logical design Functional specification Master project plan Master project schedule Budget
Functional specification management
Project tracking Plan updating
Project tracking Bug triage
Solution / scope comparison Stabilization management
Prototypes Development and technology
options Feasibility analysis
Technology evaluation Logical and physical design Development plan / schedule Development estimates
Code development Infrastructure development Configuration documentation
Bug resolution Code optimization
Problem resolution Escalation support
User Performance needs and implications
Usage scenarios / use cases User requirements Localization / accessibility
requirements User documentation, training
plans and schedules
Training Training plan updates Usability testing Graphic design
User documentation stabilization
Training materials
Training Training schedule
management
Testing approach Test acceptance criteria
Design evaluation Testing requirements Test plan and schedule
Functional testing Issues identification Documentation testing Updated test plan
Testing Bug reporting and status Configuration testing
Performance testing Problem resolution
Deployment implications Operations management and
supportability Operations acceptance criteria
Design evaluation Operations requirements Pilot and deployment plan and
schedule
Rollout checklists Rollout and pilot plan updates Site preparation checklists
Pilot setup and support Deployment planning Operations and support
training
Site deployment management Change approval
DevelopmentDevelopment
TestTest
Release Management
Release Management
UserExperience
UserExperience
ProductManagement
ProductManagement
Program Management
Program Management
69
Agenda
Introduction MSF Team Model MSF Process Model MSF Project Management Discipline MSF Risk Management Discipline MSF Readiness Management Discipline
70
Project Management
Full alignment 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
71
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
anag
emen
t
Procurem
ent M
anag
emen
t
Risk M
anag
emen
t
Communicatio
ns Man
agem
ent
Human R
esource
Man
agem
ent
Cost M
anag
emen
t
Time M
anag
emen
t
Scope M
anag
emen
t
Integrat
ion Man
agem
ent
at overall project level at sub-team level
74
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 ??? …
75
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
76
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
77
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
78
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
79
The process milestones based Approach
Segment the Project into milestones Help organize the team Facilitate communication in the team Facilitate communication with the customer YOU NEVER GET BLINDED YOU ALWAYS KNOW WHERE YOU ARE
80
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’…
81
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
83
Agenda
Introduction MSF Team Model MSF Process Model MSF Project Management Discipline MSF Risk Management Discipline MSF Readiness Management Discipline
84
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
85
Risk Considerations and Goals
Areas for consideration during risk assessment: Research. Do we know enough about this risk? Do we need to study the
risk further to acquire more information and better determine the characteristics of the risk before we can decide what action to take?
Accept. Can we live with the consequences if the risk were actually to occur? Can we accept the risk and take no further action?
Manage. Can the team do anything to mitigate the impact of the risk should the risk occur?
Avoid. Can we avoid the risk by changing the scope?
The three risk management goals are to: Reduce the probability of occurrence; Reduce the magnitude of loss; or Change the consequences of the risk.
87
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
88
Agenda
Introduction MSF Team Model MSF Process Model MSF Project Management Discipline MSF Risk Management Discipline MSF Readiness Management Discipline
89
MSF Readiness Discipline
KnowledgeSkills
Abilities
AssessAssess
ChangeChange
DefineDefine
EvaluateEvaluate
93
A few words about readiness
Readiness management is one of the least understood (and least implemented) practices– everybody claims that human resources are the most valuable capital, but virtually nobody invests in it
It is often unwise to rely on programmers’ self-assessment. Statement “5 years of Java experience” on a resume may actually refer to “5 years ago I read a book about Java”
Use certification exams for assessing team readiness. Lack of technical competence is more noticeable than lack of management
competence
94
Inheritance helps minimize bureaucracy
Option 1 Option 2
Total 64 pages
Total 34 pagesJava coding standard
C++ coding standard
C coding standard
Java coding standard
C++ coding standard
C coding standard
General style and coding standard
95
MSF Summary
Projects often fail for non-techy reasons A framework such as MSF fixes many of those problems You don’t have to use all of MSF at once If you use some bits you increase your chance of
succeeding