Microsoft Solutions Framework Executive Overview Microsofts Best Practices For IT Solutions Success...
-
Upload
austin-gallegos -
Category
Documents
-
view
218 -
download
1
Transcript of Microsoft Solutions Framework Executive Overview Microsofts Best Practices For IT Solutions Success...
Microsoft Solutions FrameworkExecutive Overview
Microsoft’s Best Practices For IT Solutions Success
Kyle KorzenowskiProduct Planner
Microsoft Business [email protected]
2© Copyright 2002 Microsoft Corporation. All rights reserved.
Agenda
IT Challenges and Opportunities
MSF Overview Team Model Process Model Risk Management
MSF Resources
3© Copyright 2002 Microsoft Corporation. All rights reserved.
The Need – Standish Group Survey
• Based on more than 23,000 IT projects
• Challenged means completed over budget or past the original deadline
• http://www.standishgroup.com/
Challenged
Succeeded
Failed 28%28%46%46%
26%26%
4© Copyright 2002 Microsoft Corporation. All rights reserved.
“When projects fail, it’s rarely technical.”
Jim Johnson, Chairman,The Standish Group
Root Causes of IT Project 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
~80% of risk/failure is due to non-technical factors.
5© Copyright 2002 Microsoft Corporation. All rights reserved.
What Is the ? 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
6© Copyright 2002 Microsoft Corporation. All rights reserved.
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!
7© Copyright 2002 Microsoft Corporation. All rights reserved.
One IT Lifecycle – Multiple Perspectives
MicrosoftSolutions
Framework
CommonDisciplines
&Shared
Responsibility
MicrosoftOperationsFramework
EnterprisePerspective
SystemsPerspective
Pla
n
Build
Dep
loy
Operate
8© Copyright 2002 Microsoft Corporation. All rights reserved.
Origin of MSF
Microsoft Worldwide Products Groups
MicrosoftInformationTechnology
MicrosoftServices
Microsoft Partners
Best Practices
Twenty-five years of Microsoft experience
MSF evolution:Since 1993
9© Copyright 2002 Microsoft Corporation. All rights reserved.
MSF Essentials
Great Teams! Fast, Effective Process!
Project Management Discipline – Getting Results
Risk Management Discipline – Minimize Surprises
Readiness Management Discipline – Anticipate & Grow Skills
Project Management Discipline – Getting Results
Risk Management Discipline – Minimize Surprises
Readiness Management Discipline – Anticipate & Grow Skills
10© Copyright 2002 Microsoft Corporation. All rights reserved.
Principles of a Successful Team
Shared project vision
Product mindset
Zero-defect mindset
Customer-focused mindset
Willingness to learn
11© Copyright 2002 Microsoft Corporation. All rights reserved.
MSF Team Model
ProgramManagement
ProgramManagement
DevelopmentDevelopment
TestingTesting
ReleaseManagement
ReleaseManagement
UserExperience
UserExperience
ProductManagement
ProductManagement
Team of Peers
12© Copyright 2002 Microsoft Corporation. All rights reserved.
Role Focus and External Coordination
13© Copyright 2002 Microsoft Corporation. All rights reserved.
Scaling Roles to Small and Large Projects
Scaling down: Teams with fewer than six people
Team members share roles Be sure all perspectives
are represented Avoid conflicts of
interest
Scaling up: Feature and/or function teams
Feature teamsMultidisciplinary sub-teams organized around feature sets
Function teamsUnidisciplinary sub-teams organized by functional role
ProgramManagement
ProgramManagement DevelopmentDevelopment
TestingTesting
ReleaseManagement
ReleaseManagement
UserExperience
UserExperience
ProductManagement
ProductManagement
14© Copyright 2002 Microsoft Corporation. All rights reserved.
Multiple Feature Teams for Large Projects
DevelopmentDevelopment
TestingTestingUserEducation
UserEducation
ProgramManagement
ProgramManagement
DevelopmentDevelopment
TestingTesting
ProgramManagement
ProgramManagement
DevelopmentDevelopment
TestingTestingUserEducation
UserEducation
ProgramManagement
ProgramManagement
ProgramManagement
ProgramManagement
DevelopmentDevelopment
TestingTesting
LogisticsManagement
LogisticsManagement
UserEducation
UserEducation
ProductManagement
ProductManagement
LeadTeam
UITeam
PrintingTeam
CoreTeam
DevelopmentDevelopment
TestTestUserExperience
UserExperience
ProgramManagement
ProgramManagement
DevelopmentDevelopment
TestTest
ProgramManagement
ProgramManagement
DevelopmentDevelopment
TestTestUserExperience
UserExperience
ProgramManagement
ProgramManagement
ProgramManagement
ProgramManagement
DevelopmentDevelopment
TestTest
ReleaseManagement
ReleaseManagement
UserUserExperience
ProductManagement
ProductManagement
LeadTeam
UITeam
PrintingTeam
CoreTeam
UserUserUserExperience
UserExperience
Experience
Function teams can also be employed.
15© Copyright 2002 Microsoft Corporation. All rights reserved.
Combining Roles for Small ProjectsProgram
ManagementProgram
Management DevelopmentDevelopment TestTest ReleaseManagement
ReleaseManagement
UserExperience
UserExperience
ProductManagement
ProductManagement
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
16© Copyright 2002 Microsoft Corporation. All rights reserved.
MSF Process Model – Phases & Milestones Deployment
complete
Envisioning
Phase
Pla
nnin
gP
hase
DevelopingPhase
Stabilizing
Phase
Deploy
ing
Phase
Vision/Scope
Approved
ProjectPlans
Approved
ScopeComplete
ReleaseReadinessApproved
17© Copyright 2002 Microsoft Corporation. All rights reserved.
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
18© Copyright 2002 Microsoft Corporation. All rights reserved.
Using Versioned Releases
Force closure on project issues
Set clear and motivational goals with all team members
Manage the uncertainty and change in project scope
Encourage continuous and incremental feature delivery
Enable shorter time to market Time
Functionality
Version 1
Version 2
Version 3
19© Copyright 2002 Microsoft Corporation. All rights reserved.
Scheduling for an Uncertain Future Create “living” documents
Baseline Early -- Baseline planning efforts begin as early as possible for an earlier development start
Freeze Late -- Consider documents as dynamic and subject to change
Schedule highest-risk and “must-have” features in early milestones Address top issues first Ensure inclusion in final product
Schedule risk-based buffer time Do NOT spread across all tasks (beware
Parkinson’s Law) Add as separate critical-path task, plan
last milestone as “nice-to-have” features
Living DocumentsLiving Documents
Functional Specifications
Vision Document
Project Plans
Project Schedule
Risk Management Document
20© Copyright 2002 Microsoft Corporation. All rights reserved.
Project Trade-off Matrix
ChosenChosenFixedFixed AdjustableAdjustable
ScheduleSchedule
Feature SetFeature Set
ResourcesResources
Res
ourc
es
Res
ourc
es
FeaturesFeatures
Schedule
Schedule
Given fixed ___________, we will choose a ___________, and adjust _________ as necessary.
Microsoft’sTypical
Approach
Fill in the blanks
21© Copyright 2002 Microsoft Corporation. All rights reserved.
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.”
22© Copyright 2002 Microsoft Corporation. All rights reserved.
Question:What’s a risk assessment? When should we consider
doing them for a project?
Risk Assessment
Risk assessment is a decision-making resource
Analysis should be comprehensive and include: identification, probability, impact, exposure, mitigating actions, contingency plans, and triggers
Assessment should be initiated as an ongoing process during any project where significant risk factors have been identified, with customer-visible risk document published with status report
A Risk realized (100% probability) becomes an Issue.
23© Copyright 2002 Microsoft Corporation. All rights reserved.
Microsoft Risk Management
Identifying, analyzing, and addressing risk proactively
To manage risk proactively
Anticipate problems vs. Fixing them when they occur
Address root causes vs. Addressing symptoms of the cause
Prevent and minimize risk vs. Reacting to consequencesthrough mitigation
Prepare for consequences vs. Reacting to a crisisto minimize impact
Use a known and vs. Using an ad-hoc processstructured process
24© Copyright 2002 Microsoft Corporation. All rights reserved.
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.
25© Copyright 2002 Microsoft Corporation. All rights reserved.
Risk Categories
Item Purpose Status
Risk Statement Clearly articulate a risk Required
Probability Quantify likelihood of occurrence Required
Impact Quantify severity of loss or magnitude of opportunity cost
Required
Ranking criterion Single measure of importance Required
Priority (rank) Prioritize actions Required
Owner Ensure follow through on risk action plans
Required
Mitigation Plan Describe preventative measures Required
Contingency plan and triggers Describe corrective measures Required
Root cause Guide effective intervention planning Optional
Downstream effect Ensure appropriate impact estimates Optional
Context Document background information to capture intent of team in surfacing risk
Optional
Time to implementation Capture importance that risk controls be implemented within a certain timeframe
Optional
26© Copyright 2002 Microsoft Corporation. All rights reserved.
Example 1 Risk Analysis Template
Status Condition Consequence Prob Impact Exposure Mitigation Contingency Triggers Owner Notes
A
If members of management involved in the project change
Then there could be a change in priorities and ideas of how to approach the project
85% 5 425 Follow assigned formal change control process
Escalate to Executive Sponsor for schedule and budget impact. Add contingency time to schedule duration to allow for these changes.
Feature Requests or schedule changes that have not followed the formal change process being initiated or expected
LH
8/26/02 - Several XYZ management
A
I f a mutually agreeable User Acceptance criteria and procedures are not developed
Then the project will not be accepted by XYZ as complete
25% 4 100 Develop agreed upon document that includes Acceptance Criteria and work with Product Management and BSS to determine Acceptance test procedures
The application meets the criteria of the Vision/Scope document and the Functional Specification
Beginning of IR3
DD
4/30/02 - BG will work with BN and the MS Dev. team to produce an initial draft of Acceptance Criteria6/05/02 - Draft reviewed with BN - additional tests need to be developed before final document is ready8/23/02 - Updated draft of User Acceptance document completed by DD and submitted to Product Mgt.
27© Copyright 2002 Microsoft Corporation. All rights reserved.
Example 2 Risk Analysis Template
Company XYZ Risk Analysis 3/18/02
Category Risk Consequence/ Impact Mitigation Owner Weight Prob. Project Impact
Date Status
Project ManagementPM 1. I f an issue escalation procedure is
not defined which facilitates open communication through all levels and interested parties and provides the framework for timely decision making,
then the project will experience ongoing issues related to lack of prioritization and decision making.
Define an issue escalation procedure that will facilitate open communication from the bottom to the top of the chain. This means that even a developer can escalate issues all the way to the business owner.
PM 2.25 75% H 09/ 04/ 02 A
PM 2. I f detailed project milestones are not identified and communicated,
then project team roles, responsibilities and task break down can not be clearly defined, resulting in false starts, poor quality, and continued delays in delivery
Establish a project plan that identifies milestones and deliverables
MR 2.25 75% H 09/04/02 A
PM 3. I f the team does not understand and agree to identified risks
then the effort to manage identified risks will be severely hindered resulting in conversion to issues
Communicate and share the risk document with all members of the team
CY 2.25 75% H 09/04/02 A
PM 4. I f time is not allocated to develop a proper deployment plan
then delivery delays can be expected Ensure time is built into the project plan post code compete to develop the deployment plan including installation procedures
CY 2.25 75% H 09/04/02 A
PM 5. I f risk monitoring is not developed as a core competency
then the project will experience ongoing issues as a result of firefighting issues
Develop and maintain a risk analysis document
PM 1.5 50% H 09/06/02 A
28© Copyright 2002 Microsoft Corporation. All rights reserved.
The Milestone-driven Process
Types of Milestones Major—culminates in a deliverable, and transitions
between phases and transitions responsibility across roles
Interim—indicates early progress and segments large work efforts into workable pieces
Function of Milestones Used as review and synchronization points Used to assess progress and to make mid-course
corrections Represents team and customer agreement to
proceed
MSF defines specific major milestones that are generic enough for any type of IT project.
29© Copyright 2002 Microsoft Corporation. All rights reserved.
Bottom-Up Estimating
30© Copyright 2002 Microsoft Corporation. All rights reserved.
Milestone-Based Estimating –“Cone of Uncertainty”
31© Copyright 2002 Microsoft Corporation. All rights reserved.
Daily Builds – A Way of Life at Microsoft “Building” an executable program from up to thousands of different files Microsoft software development teams practice the “daily build and smoke test”
process in which they compile every file, combine them into a single executable program, and put it through a “smoke test” to see if it runs.
A smoke test exercises the entire system to expose any major problems The daily build is not valuable unless accompanied by a smoke test Performing daily builds and smoke tests provides a number of important
benefits Minimizes code integration risk by identifying incompatible code early and allowing the team to
make debugging or redesign decisions Supports improved defect diagnosis, making it easier to pinpoint why the product may be
broken on any single day Reduces the risk of low quality
The team must perform the daily build and smoke test each day—not weekly or monthly—in order to produce the greatest benefits
The software must work or else the build is viewed as broken and must be fixed
Performing daily builds and smoke tests is like trying to ship a product every day, which enforces a sense of discipline upon the team.
Standards for daily builds and smoke tests vary from project to project, but at a minimum they should include:
Compiling all files and components successfully. Linking all files and components successfully. Finding no “showstopper” bugs that would make the program hazardous to
operate or prevent it from launching. Passing the smoke test.
32© Copyright 2002 Microsoft Corporation. All rights reserved.
Continuous Improvement
Post-project reviews ensure continuous learning What went well? What went poorly? What should be done differently? Recommendations for the future
Purpose is to facilitate individual and organizational learning
Post-project meetings can also be conducted at key milestones of long projects
The objective is to LEARN from the experience by facilitating a very open, blame-free
discussion of project successes and mistakes.
33© Copyright 2002 Microsoft Corporation. All rights reserved.
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
34© Copyright 2002 Microsoft Corporation. All rights reserved.
MSF Services & Support
MSF partners world-wide: Education Partners Services Partners Complimentary
Partners
Endorsement process for: MSF Practitioners
Customers & Consultants
MSF Trainers MSF Master Trainers
Upcoming books
Information Online Articles Whitepapers Online Resource
Library Templates, etc.
Online Community:Ask questions and share ideas with:
Microsoft Partners Endorsed professionals Community members
Microsoft Solution Offerings, Products,
and Services