n Introduction to the Microsoft Solutions Framework and

n. Introduction to the Microsoft Solutions Framework and the Microsoft Operations Framework Adrian Mourelos Enterprise Services Manager Microsoft Uruguay

Agenda Ø Introduction to Microsoft Solutions Framework Ø Introduction to Microsoft Operations Framework Ø Microsoft Frameworks and SEI / CMM and PMI / PMBOK Ø Questions and Answers

Microsoft Solutions Framework MSF offers guidance in how to organize people and projects to plan, build, and deploy successful IT solutions Framework Guidance Methodology List) Process Model Life Cycle (waterfall, spiral, prototype) Team Model (hierarchical, peers) Paradigm (structured, object oriented, data driven, real time) Tools, Techniques and Methods (Use Case, ERD, DFD, Event

The Origin of MSF Microsoft Worldwide Products Groups Microsoft Consulting Services Microsoft Information Technology Group Microsoft Partners n n n Proven Practices 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

Where MSF Fits in the IT Life Cycle Plan Microsoft Solutions Framework Ope rate Dep loy Buil d Microsoft Operations Framework

Goals for Successful Projects Typical Symptom of Challenged Project Related Project Goal for Success Goal Ownership “The project was late and over budget” Deliver within project constraints ? “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” Build to specifications ? Release with issues identified and addressed Deploy smoothly and prepare well for ongoing operations Enhance user effectiveness ? “It’s just too difficult to use” “It doesn’t meet our expectations we’re not happy” “Needed information is not shared timely to all who need it” – Satisfy customers Establish good communications ? ?

MSF Team Model Delivering the solution within project constraints Satisfied customers Program Management Customer Product Management Building to specification Development Communication User Experience Enhanced user effectiveness User Test Release Management Approval for release only after all quality issues are identified and addressed Smooth deployment and ongoing operations Operations There is not a Project Leader

Feature Teams Multidisciplinary sub-teams organized around product feature sets or created to focus on a particular capability Program Management Product Management Development Lead Team User Experience Release Management Program Management User Experience Desktop Feature Team Test Program Management Development User Experience File and Print Feature Team Test Messaging Feature Team Development Test

Function Teams Unidisciplinary sub-teams organized by functional role Team lead User interface design Usability research and testing Accessibility User Experience Training/support material Internationalization User advocacy

Scaling Down – Combining Roles for Smaller Teams Roles may be combined, but some combinations pose risks Product Management Program Development Management N Product Management Test User Experience Release Management N P P U N U U P N N N P P Program Management N Development N N Test P U N User Experience P U N P Release Management U P N P P Possible U Unlikely N Not Recommended U U

Example: Small Teams Small team, combined roles User Experience Program Management Product Management Release Management Test Development

MSF Process Model Phases and Milestones Deployment Complete Release Approved Vision/Scope Approved MSF Scope Complete Project Plans Approved

Designing the Solution Vision/Scope Approved Planning Phase Project Plan Approved Conceptual Design Logical Design Physical Design Conceptual Design Baseline Logical Design Baseline Physical Design Baseline

Developing Internal Releases with Daily Builds n n n Each internal release begins with a series of daily builds Testing and stabilizing follow Release occurs when interim milestone is met The Internal Release Cycle Internal Release Feature n Development Daily Builds Testing and Stabilizing Internal Buffer Release n+1 Time

ITIL & MOF Ø Ø Ø Ø MOF is full based in ITIL Industry best practices to operate systems www. CCTA. gov. uk (Central Computer and Telecommunications Agency) www. ITIL. co. uk (IT Infrastructure Library) “Service Support” “Service Delivery” MOF Team Model is considered as a best practice by ITIL

MOF Team Roles Release Security Infrastructure Partner Support Operations Ø Roles definition, their Objectives, Activities and Required Capabilities

MOF Team Model and Objectives Objective Role Change Management, Configuration Management for any IT Application Technology and Environment Management Release Customer Support and Help Desk Management Support System Management Operations Security and Assets Management and Access Control to Corporate Resources Security Partner / Vendor Management Partner Infrastructure

MOF Process Model Service Level Management Capacity Management Availability Management Financial Management Workforce Management Service Continuity Mgt Release Approved Review Optimizing Changing Release Readiness Review SLA Review Supporting Operating Service Desk Incident Management Problem Management Change Management Configuration Management Release Management Operations Review Security Administration System Administration Network Administration Service Monitoring & Control Directory Services Admin Storage Management Job Scheduling Print and Output Management

The MSF / MOF Risk Management Process Analyze and Prioritize Risk Statement Identify Control Risk Knowledge Base, Concepts, and Processes Learn Master Risk List Top n Risks Track and Report Plan and Schedule

Prioritized Master Risk List Priority Condition Consequence Probability Impact Exposure 1 Developers to work with new shipping technology Development time will take longer due to the need for developers to learn 30% 2 . 6 2 Development team is divided between London and Los Angeles Communicatio n among the team members will be difficult 20% 2 . 4

How the CMM for Software looks like? Level Focus Key process areas 5: Optimizing Continuous process improvement Ø Defect prevention Ø Technology change management Ø Process change management 4: Managed Product and process quality Ø Quantitative process management Ø Software quality management 3: Defined engineering process at organizational level Ø Organizational process focus Ø Organizational process definition Ø Integrated software management Ø Software product engineering Ø Intergroup coordination Ø Peer reviews 2: Repeatable Project management and commitment process Ø Requirements management Ø Project planning Ø Project tracking and oversight Ø Software subcontract management Ø Software quality assurance Ø Software configuration management 1: Initial Heroes

Transition from Level 1 to Level 2 n Working at Level 1 u Reinventing Processes as They Work u Avoiding Uncontrolled Commitments n Moving to Level 2 u Controlling the Requirements u Managing Daily Project Activities u Using Configuration Management and Quality Assurance u Managing Vendor Work u Tracking to a Sound Plan

Moving from Level 2 to Level 3 using MSF and MOF CMM Level 2 Key Area MSF / MOF related Processes Requirements Management Vision / Scope document, Functional Specification Project Planning High level planning during Envisioning, details during Planning; establishing trade-offs Project Tracking and Oversight Software Configuration Management Milestones driven life cycle, formal Risk Management process MOF SCM discipline, Build’s driven approach Software Quality (Process) Assurance Defining Project Quality Level (MSF); MOF Service Level Management; Software Engineering Group MOF Subcontractor Management, MSF Independent Team Roles Software Subcontract (Vendor) Management

The Project Management Discipline “Project management is the application of knowledge, skills, tools, and techniques to project activities to meet project requirements” (Project Management Institute) Does not equate to “being the boss” Ø Is especially critical for scaled-up project teams Ø

Distributing Project Management on Large Projects Team leads for each role own the responsibilities corresponding to the listed knowledge areas t n me t nt e e n em n a a g m t nt t M e M an a t n t e ge n n s a m me me n o u r c n t M em e ag em e a i t e g e e ag an n M an a n ag n i c a R es n m o i a e M a u an ur k M lity r at p e M t M a m c g m um o s s e o R i Qu a Pr H Co In t Ti m Co Sc nt Team Leads n me e ag Program Management Product Management Development Test User Experience Release Management at overall project level at sub-team level

Questions and Answers