1. DEV238 A-to-Z of MSF v3 (Microsoft Solutions Framework) Rafal Lukawiecki rafal@projectbotticelli.co.uk www.projectbotticelli.co.uk Strategic Consultant Project Botticelli Ltd Session partially based on excellent materials for new MSF course 1846

2. 2 My Objective Relate to key reasons why projects fail Convince you MSF can help solve many project issues Explain the innovation in MSF v3 Give you tips on how to start using MSF Connect MSF to MOF

3. 3 Agenda What is MSF v3 Statistics The Useful Bits of MSF v3 Implementing MSF And there will be a video on an MSF case study: UK eGovernment

4. 4 MSF Microsoft Solutions Framework Established in 1991, last major revisions in 1998 and January 2003 (v3). Related to MOF, Microsoft Operational Framework Which concentrates on the management of IT infrastructure

5. 5 Lifecycle of IT Microsoft Operations Framework Microsoft Solutions Framework Operate Deploy Build Plan

6. 6 Project Failure Rates 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 SucceededChallengedFailed

7. 7 Does it Work? Yes, as long as you chose the right bits of MSF for your project High-profile projects that used MSF www.nasdaq.comwww.nasdaq.com and www.marriott.com (Aris Corp, now Ciber, www.ciber.co.uk)www.marriott.com Visual Studio, Windows 2003, Windows XP

8. 8 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 (RUP, Prince 2, etc.) No, because you have to make choices

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

10. 10 “When projects fail, it’s rarely technical.” Jim Johnson, The Standish Group Root Causes of 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 Solution? A good and tested framework! Average cost overrun: 189% Time overrun: 222% Projects re-started: 94% Functionality delivered on average: 61% Standish Group

11. 11 Key MSF Components Risk Management Discipline Process Model Team Model Project Management Discipline Readiness Management Discipline Models Disciplines

12. 12 Key MSF Components

13. 13 A Team of Peers 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 Test Release Management User Experience Product Management Program Management

14. 14 Scaling The Model You can combine some roles to teams as small as 3 people Do not combine some (like Product and Program Manager, or anything with Developer) You can scale it to 10, 100s and 1000s by using two methods: Functional Teams (many people for one role) Feature Teams (sub-teams for each feature)

15. 15 Project Management Full alignement 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

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

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

18. 18 Daily Build Building the product in an executable form on a daily basis A public daily build is A strong indicator that a team is functional A way to make the product and its progress visible The heartbeat of the development process

19. 19 Internal Releases Daily builds lead to internal (alpha releases) Internal Release n Internal Release n + 1 Testing and Stabilizing Buffer Time Feature Development Daily Builds

20. 20 Can I Really Build Every Day? On a typical 4-6 month project, you will not be ready for a daily build for the first 3- 5 days at the most Then you can!

21. 21 How Does Daily Build Work? A A → A’ B C B A B → B’ C C A B C → C’ A A’ B C’ B A’ B, B’ C’ C A’ B C’ A’’ From A’ B’’ From B and B’ C’’ From C’ → Day 1Day 2Day 3BVT →→→→

22. 22 Tips for Daily Build Use source-code control system (such as Microsoft Visual Source Safe, Rational ClearCase etc.) Each developer works locally, i.e. all code and executables on every station Every day code is collected, built and published and every morning developers download the newest build Designate quality levels (BVT, TST, IDW, IDS, IDC – Microsoft “speak”) Automate it all (batch files etc.) Developing them is an ongoing activity that will be complete when your first project completes Use Visual Studio.NET 2003 with MSDN Universal – there is new automation for daily build in it!

23. 23 Release Readiness Ongoing Process of Testing D E V L O P I G E N S T A B I L Z N G I I Project Plan Approved Project Plan Approved Scope Complete Internal Release 1 Internal Release 2 Internal Release... Test Plan Test Specification Complete/Alpha Betas Release Candidates Golden Release/RTM Release Internal Release n (Alpha, Pilot) Zero-Bug Bounce Product Stability

24. 24 Retired Risks Risk Assessment Document Top 10 3. Plan5. Control 2. Analyze 1. Identify Risk Statements 4. Track Risk Management Process

25. 25 Design Process Overview Logical Design Conceptual Design Scenarios Physical Design Components, User Interface, and Physical Database Components, User Interface, and Physical Database Objects and Services, User Interface, and Logical Database Objects and Services, User Interface, and Logical Database

26. 26 Relationship to Planning Project Plan Approved Project Plan Approved Physical Design Baseline Conceptual Design Logical Design Physical Design Vision Approved Vision Approved Logical Design Baseline Conceptual Design Baseline

27. 27 video video Does It Work? UK eGovernment Case Study

28. 28 Implementing MSF

29. 29 Getting MSF in 7 Steps 1. Select a group of senior decision makers and present them an executive summary (e.g. this presentation and Q&A) 2. Selects a pilot development group and project (6-10 people, 4-6 months, new project) 3. Train on MSF Essentials MOC #1846 course 4. Optionally, appoint a consultant to provide “health feedback” 5. Executes the project successfully 6. Revise and customise MSF if needed 7. Optionally, plan and restructure the organisation if the success is worth repeating

30. 30 What If My And Customer’s Teams Are Mixed? Most partners have a “fun” time winning and running these projects Teach the customer MSF before the project starts as a “closed” (private) course They will trust you more They will be more likely to succeed by understanding how you work You are much more likely to win the project Make sure you have someone responsible for all roles – do not “split the team” (i.e. you are Program Manager and customer provides a Product Manager) Conflict of interests

31. 31 Summary Projects fail for non-techy reasons A framework such as MSF fixes that problem You don’t have to use all of MSF at once If you use some bits you increase your chance of succeeding

32. 32 Resources & Actions Visit www.microsoft.com/msfwww.microsoft.com/msf Attend course “MSF Essentials” MOC #1846 Pass the “MSF Practitioner” Prometric test Read: “Dynamics of Software Development” by Jim McCarty, Microsoft Press I’ll eventually have a book out on this subject…

33. 33 Community Resources http://www.microsoft.com/communities/default.mspx Most Valuable Professional (MVP) http://www.mvp.support.microsoft.com/ Newsgroups Converse online with Microsoft Newsgroups, including Worldwide http://www.microsoft.com/communities/newsgroups/default.mspx User Groups Meet and learn with your peers http://www.microsoft.com/communities/usergroups/default.mspx

34. 34 evaluations evaluations

35. 35 © 2003 Microsoft Corporation & Project Botticelli Ltd. All rights reserved. This presentation is for informational purposes only. MICROSOFT AND PROJECT BOTTICELLI MAKE NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.