Microsoft Solutions Framework Overview. Challenges & Opportunities MSF. Scope of Enterprise IT

(1)

Microsoft Solutions Framework

Overview

DI Andreas Schabus

[email protected] Academic Relations Manager Microsoft Österreich GmbH

solution: [s&-‘lü-sh&n]

1: an action or process of solving a problem 2: an answer to a problem

Scope of Enterprise IT

4 4

MSF

Framework: [‘frAm-“w&rk]

1: a basic conceptional structure (as of ideas) 2: a skeletal, openwork, or structural frame

Project Issues

Call to action

Adopt Key Concepts Learn about MSF Adopt MSF

Challenges & Opportunities

Escalating business expectations of technology

Increasing business impact of technology

solutions

Risks are higher than ever before

Optimizing scarce resources

Skilled people, budget, time, and other assets

Rapid technology evolution

Many new opportunities, but they require new skills and effective teams to take advantage of them

(2)

“This thing is unpredictable – we

keep discovering new problems”

Symptoms of Challenged Projects

“It’s just too difficult to use”

“We couldn’t get the information

we needed to do our work”

“We were unaware of how the work of other team members

affected our work” “The project

was late and over budget”

“What was built really isn’t what we needed” “It doesn’t meet

our expectations –

we’re not happy” “We didn’t

understand clearly what we were supposed to do”

“We can’t get it to operate

well in our environment”

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

Succeeded Challenged

Failed

Root Causes of Technology Project Failure

Disconnected stakeholders

No executive sponsorship Limited user participation Operations involved too late

Team environment

Team/culture issues Perceived constraints Not open and honest

Vague process Unclear approach Unstated goals Managing scope Teamwork barriers Responsibilities unclear Conflicting language Poor communications

Most causes are related to

“people and process” – not technology

Microsoft Solutions Framework

Key goals for MSF:

Drive business success through business & technology alignment

Ensure high quality solutions; handling the many facets of quality as defined by multiple stakeholders

Accelerate delivery, reduce costs, minimize risks Improve team effectiveness

MSF offers guidance in how to organize

people and projects to plan, build, and

deploy technology solutions

successfully and effectively

(3)

_Origin

Foundation Princi_ples

Key Concepts / Pr_{oven Practices}

_Models _Team _Process Disciplines

Project Managem_ent

Risk Management

Readiness Manag_ement

MSF Checklist

Changing Operating Supporting Optimizing Business Need Service Delivered

Following a Solution Through the IT Lifecycle

The Origin of MSF

Results from project teams and product groups are analyzed

Analyzed results are contrasted with industry practices and methods

Combined results are then organized and consolidated into “people and process” guidance

Microsoft Products Groups Microsoft Operations & Technology Group Microsoft Services Microsoft Certified Partners Proven Practices ;_Origin

Project Managem_ent

Risk Management

(4)

MSF Foundational Principles

Clear accountability, shared responsibility

Empower team members

Focus on business value

Shared project vision

Stay agile, expect change

Foster open communications

Learn from all experiences

Invest in quality

Example of a Vision

“I believe this nation should commit itself to achieving the goal …

of landing a man on the Moon and returning him safely to the Earth. No single space project … will be more

impressive to mankind, or more important for the long-range

exploration of space… .”

President John F. Kennedy Speech to U.S. Congress May 25, 1961

Scope

Scope – The parts of the vision that can be accomplished within the solution constraints

Solution scope - The sum of the products and services to be provided as a solution

Project scope – The work performed by the team to deliver each item in the solution scope

Solution Scope Project Scope

Your project may not include the entire solution

A single solution may spawn several serial or concurrent projects

Solution Scope Project Scope Project Scope ;_Origin ;

Project Managem_ent

Risk Management

(5)

Key Concepts and Proven Practices

Key concepts

Team of peers

Customer-focused mindset

Product mindset

Zero defect mindset

Willingness to learn

Proven practices

Use small, interdisciplinary teams

Enable teams to work together at a single site

Create a solution design through total team

participation

;_Origin ;

;

Project Managem_ent

Risk Management

MSF Checklist

Establish good communications

Related Project Goal for Success

Deliver within project constraints

Build to specifications Release with issues identified and addressed

Deploy smoothly and prepare well for ongoing operations Enhance user effectiveness “The project was late and over

budget”

“What was built really isn’t what we needed”

“This thing is unpredictable– we keep discovering new problems”

“We can’t get it to operate well in our environment”

“It’s just too difficult to use”

Goals for Successful Projects

Typical Symptom of Challenged Project

Satisfy customers

Goal Ownership

“It doesn’t meet our expectations – we’re not happy”

? ? ? ? ? ?

“Needed information is not shared

timely to all who need it” ?

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 Development Development Test Test Release Release Management Management User User Experience Experience Product Product Management Management Program Program Management Management

(6)

MSF Team Model: Functional Areas

Business value Marketing Customer advocacy Product planning Project management Solution architecture Process assurance Administrative services Technology consulting Implementation architecture and design Application development Infrastructure development Test planning Test engineering Test reporting Infrastructure Support Operations Logistics Commercial release management Accessibility Internationalization User advocacy Training/support material Usability research and testing User interface design

Development Development Test Test Release Release Management Management User User Experience Experience Product Product Management Management Program Program Management Management

The Extended Project Team

Operations and Support Groups Technology Focus Business Focus Users Project Sponsor Customer

Technology Architects and Steering Committees Help Desk Project Team User Experience Development Test Release Management Product Management Program Management

Using Sub-Teams for Large Projects

Function team

Feature teams

Lead team

Program Program Management Management Release Release Management Management Product Product Management Management User User Experience Experience Development Development Test Test Catalog Program Management Development Test

Site Engine & Design Program Management User Experience Development Test Fulfillment Program Management User Experience Development Test User Experience Release Management

Scaling Down – Combining Roles

for Smaller Teams

Roles maybe combined, but some combinations pose risks

N N N N N N N N N N N N P P P P P P P P P P U U U U U U U U

P Possible U Unlikely N Not Recommended

Product Product Management Management Program Program Management

Management DevelopmentDevelopment TestTest

User User Experience Experience Release Release Management Management Product Product Management Management Program Program Management Management Development Development Test Test User User Experience Experience Release Release Management Management

(7)

User Experience User Experience Product Management Product Management Test Test Program Management Program Management Release Management Release Management Development Development

Example: Small Team

Small team, combined roles

Product

tbd

Product

tbd

Sample: Project Team

Project Executive 3 x tbd Project Executive 3 x tbd Project Board 3 x tbd Project Board 3 x tbd Project Director tbd Project Director tbd Project Office 3x tbd Project Office 3x tbd Supportability tbd Supportability tbd Test tbd Test tbd Program tbd Program tbd Dev tbd Dev tbd User XP tbd User XP tbd Logistics tbd Logistics

tbd _Engineer_EngineerAllianceAlliance Logistics 4 x tbd Logistics 4 x tbd Architect tbd Architect tbd Build tbd Build tbd User XP 2 x tbd User XP 2 x tbd Test 2 x tbdTest 2 x tbd Program tbd Program tbd Dev 3 x tbdDev 3 x tbd Core

Exchange 3 x tbd3 x tbdTestTest

Program tbd Program tbd Dev 5 x tbdDev

5 x tbd Portal 4 x tbd4 x tbdTestTest

Program 2 x tbd Program 2 x tbd Dev 5 x tbdDev 5 x tbd Integration Performance tbd Performance tbd Leads ;_Origin ;

;

_Models ; _Team _Process Disciplines

Project Managem_ent

Risk Management

MSF Checklist

Pre-Production Testing Complete

MSF Process Model

Project Plans Approved Scope Complete Release Readiness Approved Deployment Complete Vision/Scope Approved Pilot 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 Complete Internal Release 1 Internal Release 2 Internal Release n Project Plans Approved Scope Complete Release Readiness Approved Deployment Complete Vision/Scope Approved Pilot Complete Pilot Complete --Release Candidates 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 Complete Internal Release 1 Internal Release 2 Internal Release n

(8)

The MSF Process Model Is Iterative

Time

Functionality

Minimize risks by breaking large projects into multiple versions

Version 1

Version 2

Version 3

Milestone

MSF Role Cluster

Vision/scope approved Product management Project plans approved Program management Scope complete Development

User experience Release readiness approved Testing

Release management Deployment complete Release management

Different Roles Drive Different Phases

MSF Team Roles Through the Phases

Problem resolution Escalation support Bug resolution Code optimization Code development Infrastructure development Configuration documentation Technology evaluation Logical and physical design Development plan / schedule Development estimates Prototypes Development and technology options Feasibility analysis Solution / scope comparison Stabilization management Project tracking Bug triage Functional specification management Project tracking Plan updating Conceptual and logical design Functional specification Master project plan Master project schedule Budget Design goals Solution concept Project structure Customer feedback, assessment, signoff Communication s plan execution Launch planning Customer expectations Conceptual design Business requirements analysis Communication s plan Overall goals Identify customer requirements Vision / scope document Deploying Phase Stabilizing Phase Developing Phase Planning Phase Envisioning Phase Development Product Management Program Management

MSF Team Roles Through the Phases

Site deployment management

Change approval

Pilot setup and support Deployment planning Operations and support training Rollout checklists

Rollout and pilot plan updates Site preparation checklists Design evaluation Operations requirements Pilot and deployment plan and schedule Deployment implications Operations management and supportability Operations acceptance criteria Performance testing Problem resolution Testing Bug reporting and status Configuration testing Functional testing Issues identification Documentation testing Updated test plan Design evaluation Testing requirements

Test plan and schedule Testing approach Test acceptance criteria Training Training schedule management User documentation stabilization Training materials Training Training plan updates Usability testing Graphic design Usage scenarios / use cases User requirements Localization / accessibility requirements User documentation, training plans and schedules User Performance needs and implications Deploying Phase Stabilizing Phase Developing Phase Planning Phase Envisioning Phase Test Release Management User Experience

(9)

The Tradeoff Triangle

The Tradeoff Triangle represents the

variable relationship between

resources, schedule, and features

Fixed Chosen

Resources

Features Schedule

Adjustable

MSF Project Trade-off Matrix

The MSF tradeoff matrix is an early agreement

made between the team and stakeholders

The Tradeoff Matrix - an agreement between the team and customer to set default priorities for tradeoff decisions

Establishing Traceability

Ensuring that end

results meet initial

business goals and

requirements

Business Goal Solution Requirements User Profiles Solution Concept

Conceptual Design View Logical Design View Physical Design View Functional Specification

Plans Schedule

;_Origin ;

;

;_Models ; _Team ; _Process Disciplines

Project Managem_ent

Risk Management

(10)

MSF Project Management Discipline

Project management is an area of knowledge, skills, tools, and techniques to achieve project objectives within project constraints

In MSF, project management is a service, with many responsibilities shared among roles

Does not equate to “being the boss”

Is especially critical for scaled-up project teams

MSF was designed to work in conjunction with several industry project management standards around the world including:

The Project Management Institute (PMI) Body of Knowledge (PMBOK) The International Project Management Association (IPMA)

Prince2

MSF enhances generic PM practices with techniques, milestones, and practices specifically appropriate for technology projects

Project Management Knowledge Areas

Project integration management

Project scope management

Project schedule management

Project cost management

Project staff resource management

Project communications management

Project risk management

Project procurement management

Project quality management

;_Origin ;

;

;_Models ; _Team ; _Process Disciplines ;

Project Managem_ent

Risk Management

MSF Checklist

Definitions

Risks

“Possibility of loss or injury,” Webster’s

Collegiate Dictionary, 10th edition

An anticipated problem or future potential

for adverse outcome, loss, or harm

Risk management

Process of identifying risks and managing

those that are most threatening to the

project

(11)

Risk Management in MSF

Project Risk – The possibility of a

negative outcome that is assumed in

order to pursue an opportunity for gain in

the project

MSF risk management discipline

Distinguishes risks from issues or problems

that exist

already

(“known problems”)

Defines a risk management process for

proactively identifying, analyzing, and

addressing risks

Increases the likelihood of success in a

project by minimizing the potential for failure

MSF Risk Management Discipline

Key Concepts

Assume risk is inherent in any project or

process

View risk identification as a positive

activity

Specify risks first, then manage them

Assess risks continuously

Use proactive risk management

Do not judge value of project simply by

the number of risks

Foundational Principles Applied to

MSF Risk Management

Stay agile, expect change

Embrace change and turn it into opportunity

Continuously assess and proactively manage

risks

Foster open communications

Encourage a no-blame culture

Discuss risks openly to enable better informed

decision-making

Foundational Principles and MSF

Risk Management (cont.)

Establish clear accountability, shared

responsibility

Hold program management role accountable for risk

management activities

Share responsibility for participating in the risk

management process among all team members

Share responsibility for assigned risks and action

items among individual team members

Learn from all experiences

Apply learning to achieve continuous improvement

and greater success

(12)

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 vs.Reacting to consequences through

risk mitigation

Prepare for vs.Reacting to a crisis

consequences to minimize impact Use a known and vs.Using an ad hoc process structured process

MSF Risk Management Discipline

Creating Risk Statements

…we may ship with more bugs

Total Loss or Opportunity Cost

Risk Statement

Risks must be clearly stated

Consequence Condition

Root Cause

Therefore The development and

test roles have been combined in this project

Deriving Risk Sources from Risk

Classifications

Risk classifications can be used to stimulate thought

regarding risk sources

Risk Sources Risk

Classifications

Laws, regulations, competition, economy, technology, and business

Environment

Customers, end users, stakeholders, personnel, organization, skills, and politics

People

Security, development and test environments, tools, deployment, support, operations environment, and availability

Technology

Mission and goals, decision-making, project characteristics, budget, costs, schedules, requirements, designs, building, and testing Process

Arriving at the Initial Risk List

Downstream Effect Consequence Condition Root Cause Classification We get to the market later and lose market share to competitors Development time will take longer due to the need for developers to learn Developers to work with new shipping technology Technology change Technology Delays in product shipment with additional rework Communicatio n among the team members will be difficult Development team is divided between London and Los Angeles Organization People

(13)

Exposure Impact Probability Consequence Condition Priority

Arriving at a Prioritized Master Risk List

.4 2

20%

Communication among the team members will be difficult

Development team is divided between London and Los Angeles

2

.6 2

30%

Development time will take longer due to the need for developers to learn Developers to work with new shipping technology 1 Owner Trigger Contingency Mitigation Consequence Condition Development team is divided between London and Los Angeles Communicatio n among the team will be difficult Hold a weekly team meeting via teleconference between London and Los Angeles Establish an internet-based communication portal for posting important project information Lack of communication results in schedule slippage Developers to work with new shipping technology Development time will take longer due to need for developers to learn Provide technical training to developers Revert back to previous version Developers have not passed related technology exam by project plan approval

Documenting Risk Action Plans

Erik Ismert Brenda Diaz Analyze and Analyze and Prioritize Prioritize Master Risk List Top n Risks Plan and Plan and Schedule Schedule Identify Risk Statement Control Control

The MSF Risk Management Process

Learn Learn Risk Knowledge Base, Concepts, and Processes Track and Track and Report Report ;_Origin ;

;

;_Models ; _Team ; _Process Disciplines ;

Project Managem_ent

;

Risk Management

(14)

MSF Readiness Management Discipline

Unknown knowledge assets

vs. Develop and use a

knowledge management system

Conduct training or fix gaps as they occur vs.

Anticipate and schedule readiness needs

Using and ad hoc process or none at all

vs. Use a known and

structured process

React to shortfalls in knowledge, skills, abilities vs. Treat readiness planning as positive

Reactive

vs.

Proactive

Readiness Management: A Proactive Approach

Every project is a learning opportunity

Defining the Type of Project for

Skills Requirements

Source: Based on the Cranfield Information Systems Research Centre’s Application Portfolio Planning

Strategic Critical to sustain future business opportunity High Potential Important to achieve future success Key Operational Dependency for current success Support

Valuable, but not critical to success

Skill Build

ing

Skill Maintenance

Proactive Reactive

The MSF Readiness Management

Process

Knowledge Skills Abilities Assess Change Define Evaluate ;_Origin ;

;

Key Concepts / Pro_{ven Practices}

;_Models ; _Team ; _Process ; Disciplines ;

Project Managem_ent

;

Risk Management

;

http://www.m

icrosoft.com

/msf

(15)

http://www.micros_{oft.com/austria/ed} uc ation http://de.thespoke.n_et http://Imagine.the_spoke.net http://www.stud_{entoptions.com} http://research.m_icrosoft.com http://blogs.msdn_{.com/bloggers.aspx}

Maybe interesting?

©