1. 1 MSF: Microsoft Solutions Framework

2. 2 Agenda  Introduction  MSF Team Model  MSF Process Model  MSF Project Management Discipline  MSF Risk Management Discipline  MSF Readiness Management Discipline

3. 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. 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. 5 Framework: Supplementing Methodologies 1st Avenue Plum Street Orange Street.. 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. 6 One IT Lifecycle – Multiple Perspectives Microsoft Solutions Framework Common Disciplines & Shared Responsibility Microsoft Operations Framework Enterprise Perspective Systems Perspective Plan Build Deploy Operate

7. 7 Origins of MSF Microsoft Worldwide Products Groups Microsoft Information Technology Microsoft Information Technology Microsoft Consulting Services Microsoft Consulting Services Microsoft Partners Best Practices Microsoft 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. 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. 9 A Brief History 1994 1995 1997 1999 2002 2005-06 MSF Offering MSF v1 21 Rules “Dynamics” Solutions Dev Discipline (SDD) MSF v2 Principles of … App Dev (PAD) Infra Deploy (PID) Ent Arch (PEA) Comp Des (PCD) MSF v2.5 MSF v3 Essentials + Exam Core Agile CMMI … MSF v4

10. 10 MSFv4 Family Tree Framework Methodology MSF for Agile Software Development MSF for CMMI ® Process Improvement Infrastructure MSFv4 Core Application Development Discipline Product(instantiated) Family

11. 11 Content Relationship MSFv4 “Core” Discipline Infrastructure MSF for Agile Software Development MSF for CMMI ® Process Improvement Product Application Development Family MSF v4 MSF v3 Infrastructure CMMI Agile

12. 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. 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. 14 Where MSF Fits in the IT Life Cycle Microsoft Operations Framework Microsoft Solutions Framework Operate Deploy Build Plan

15. 15 Risk Management Discipline Process Model Team Model Project Management Discipline Readiness Management Discipline Key Parts of MSF Models Disciplines Getting Results Minimize SurprisesAnticipate & Grow Skills

16. 16 MSF Foundational Principles

17. 17 Agenda  Introduction  MSF Team Model  MSF Process Model  MSF Project Management Discipline  MSF Risk Management Discipline  MSF Readiness Management Discipline

18. 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. 19 MSF Team Model Program Management Program Management Development Testing Release Management Release Management User Experience User Experience Product Management Product Management Team of Peers

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

21. 21 MSF Team Model

22. 22 MSF Team Model

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

28. 28 Test Role

29. 29 User Experience Role

30. 30 Release Management Role

31. 31 Roles & Responsibilities

32. 32 Principles of a Successful Team  Shared project vision  Product mindset  Zero-defect mindset  Customer-focused mindset  Willingness to learn

33. 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.”

34. 34 Principles of a Successful Team

35. 35 Combining Roles for Small Projects

36. 36 Product Management Product Management Teams: Scaling Down Program Management Program Management Development Testing Release Management Release Management User Experience User Experience

37. 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. 38 Feature Teams Multidisciplinary sub-teams organized around product feature sets or created to focus on a particular capability Program Management Release Management Product Management User Experience Development Test Lead Team Desktop Feature Team Program Management User Experience Development Test File and Print Feature Team Program Management User Experience Development Test Messaging Feature Team Program Management User Experience Development Test

39. 39 Example: Function Team Group Product Management Evangelism Public Relations Marketing Product Planning Product Management Product Management

40. 40 Functional Teams Marketing

41. 41 MSF Team Role Clusters and Their 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 Test Release Management User Experience Product Management Program Management

42. 42 Agenda  Introduction  MSF Team Model  MSF Process Model  MSF Project Management Discipline  MSF Risk Management Discipline  MSF Readiness Management Discipline

43. 43 MSF Process Model Project Plans Approved Scope Complete Release Readiness Approved Deployment Complete Vision/Scope Approved MSF

44. 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. 45 MSF Process Model Is an Iterative Approach Time Functionality Minimize risks by breaking large projects into multiple versions Version 1 Version 2Version 3

46. 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. 47 Envisioning Phase  Deliverables  Vision/scope document  Project structure document  Initial risk assessment document

48. 48 Vision Components

49. 49 Vision Components

50. 50 Planning Phase Deliverables:  Functional specifications  Master project plan  Master project schedule

51. 51 Planning Components

52. 52

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

54. 54 Developing Components

55. 55 Developing Phase

56. 56 Zero Defect Mindset

57. 57 Daily Build

58. 58 Stabilizing Phase Deliverables:  Pilot review  Release-ready versions:  Source code and executables  Scripts and installation documentation  End-user help and training materials  Operations documentation  Release notes  Testing and bug reports  Project documents

59. 59 Stabilizing Components

60. 60 Bug Convergence

61. 61 MSF Testing the Solution Testing is part of the build cycle, not a standalone activity Release Readiness Approved Scope Complete Project Plans Approved

62. 62 Team Focus During Stabilizing Phase

63. 63 Deploying Phase  Deliverables  Operations and support information systems  Repository of all versions of docs, load sets, configs, scripts, and code  Project close-out report

64. 64 Team Focus During Deploying Phase

65. 65 MSF Phases and Milestones Project Plans Approved Scope Complete Release Readiness Approved Deployment Complete 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 Complete Internal Release 1 Internal Release 2 Internal Release n

66. 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. 67 Envisioning PhasePlanning PhaseDeveloping PhaseStabilizing PhaseDeploying 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 Development Test Release Management User Experience Product Management Program Management

68. 68 Team Participation

69. 69 Agenda  Introduction  MSF Team Model  MSF Process Model  MSF Project Management Discipline  MSF Risk Management Discipline  MSF Readiness Management Discipline

70. 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. 71 Project Management Team 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 Management Procurement Management Risk Management Communications ManagementHuman Resource Management Cost Management Time Management Scope Management Integration Management at overall project level at sub-team level

72. 72 Specialization of Program Management

73. 73 Making Project Trade-offs Resources Features Schedule Quality

74. 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. 75 Project Trade-off Matrix Constrain Optimize Accept Schedule Features Resources Features 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. 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. 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. 78 MilestoneMSF Role Cluster Vision/scope approvedProduct management Project plans approvedProgram management Scope completeDevelopment User experience Release readiness approvedTesting Release management Deployment completeRelease management Different Roles Drive Different Phases

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

82. 82 Accountability

83. 83 Agenda  Introduction  MSF Team Model  MSF Process Model  MSF Project Management Discipline  MSF Risk Management Discipline  MSF Readiness Management Discipline

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

86. 86 MSF Risk Management Discipline

87. 87 Analyze and Prioritize Master Risk List Top n Risks Plan and Schedule Identity Risk Statement Control The MSF Risk Management Process Learn Risk Knowledge Base, Concepts, and Processes Track and Report The ongoing deliverable of this process is a living risk assessment document

88. 88 Agenda  Introduction  MSF Team Model  MSF Process Model  MSF Project Management Discipline  MSF Risk Management Discipline  MSF Readiness Management Discipline

89. 89 MSF Readiness Discipline Knowledge Skills Abilities Assess Change Define Evaluate

90. 90 Types Of Rediness

91. 91 Types Of Readiness

92. 92 Rediness Management Tasks

93. 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. 94 Inheritance helps minimize bureaucracy Option 1Option 2 Total 64 pages Total 34 pages Java coding standard C++ coding standard C coding standard Java coding standard C++ coding standard C coding standard General style and coding standard

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

96. 96 MOF Summary “Enterprises operating a predominantly Microsoft environment should investigate MOF early. Enterprises in a heterogeneous environment should focus on ITIL and selectively pick best practices from MOF.”