Introduction to Microsoft Solutions Framework and Microsoft Operations Framework

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

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

3. Microsoft Solutions Framework MSF offers guidance in how to organize people and projects to plan, build, and deploy successful IT solutions Framework  Guidance Methodology 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 List)

4. Microsoft Worldwide Products Groups Microsoft Consulting Services ProvenPractices Microsoft Information TechnologyGroup Microsoft Partners 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

5. Where MSF Fits in the IT Life Cycle Microsoft Solutions Framework Plan Operate Build Deploy Microsoft Operations Framework

6. 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” Build to specifications ? “This thing is unpredictable– we keep discovering new problems” Release with issues identified and addressed ? “We can’t get it to operate well in our environment” Deploy smoothly and prepare well for ongoing operations ? “It’s just too difficult to use” Enhance user effectiveness ? “It doesn’t meet our expectations –we’re not happy” Satisfy customers ? “Needed information is not shared timely to all who need it” Establish good communications

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

8. ProgramManagement ProgramManagement Development Development DesktopFeatureTeam MessagingFeatureTeam UserExperience UserExperience Test Test ProgramManagement Development File and Print FeatureTeam UserExperience Test Feature Teams Multidisciplinary sub-teams organized around product feature sets or created to focus on a particular capability ProgramManagement ProductManagement Development Lead Team UserExperience Test ReleaseManagement

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

10. N N P P U N N U U P N N N N N U N P P P U N P U P P N P U U Scaling Down – Combining Roles for Smaller Teams Roles may be combined, but some combinations pose risks ProductManagement ProgramManagement UserExperience ReleaseManagement Development Test ProductManagement ProgramManagement Development Test UserExperience ReleaseManagement P Possible U Unlikely N Not Recommended

11. UserExperience ProgramManagement Development ProductManagement Test Example: Small Teams Small team, combined roles ReleaseManagement

12. MSF Process Model Phases and Milestones DeploymentComplete Release Approved Vision/Scope Approved MSF Project Plans Approved Scope Complete

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

14. Internal Release n Internal Release n + 1 Feature Development Buffer Time Testing and Stabilizing Daily Builds Developing Internal Releases with Daily Builds • 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

15. 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

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

17. Objective Role Change Management, Configuration Management for any IT Application Release Technology and Environment Management Infrastructure 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 MOF Team Model and Objectives

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

19. The MSF / MOF Risk Management Process Analyze andPrioritize RiskStatement MasterRisk List Identify Plan andSchedule Control Top nRisks Track andReport Learn RiskKnowledge Base,Concepts,and Processes

20. Prioritized Master Risk List 1 Developers to work with new shipping technology Development time will take longer due to the need for developersto learn 30% 2 .6 2 Development team is divided between London and Los Angeles Communication among the team members will be difficult 20% 2 .4

21. How the CMM for Software looks like?

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

23. 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 Milestones driven life cycle, formal Risk Management process Software Configuration Management MOF SCM discipline, Build’s driven approach Software Quality (Process) Assurance Defining Project Quality Level (MSF); MOF Service Level Management; Software Engineering Group Software Subcontract (Vendor) Management MOF Subcontractor Management, MSF Independent Team Roles

24. 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

25. Risk Management Procurement Management Communications Management Human Resource Management Integration Management Time Management Cost Management Scope Management Quality Management Distributing Project Management on Large Projects Team leads for each role own the responsibilities corresponding to the listed knowledge areas at overall project level at sub-team level

26. Questions and Answers