Copyright © 2003 by IDAG Ltd. What is MSF V3 And why should I, as a Manager, Developer, Deployer, Integrator or Customer, care about it Gad J. Meir IDAG Ltd. Copyright © 2003 by IDAG Ltd. and Gad J. Meir. All rights reserved. (Some parts quote Microsoft public materials). This presentation, its workshops, labs and related materials may not be distributed or used in any form or manner without prior written permission by the author(s).

Copyright © 2003 by IDAG Ltd. About the Lecturer Gad J. Meir IDAG Ltd. B.Sc in Computer Engineering, Technion - Technical Institute of Israel MCSE, MCSD, MCT and most other Microsoft Certifications Certified MSF Trainer,Microsoft International

Copyright © 2003 by IDAG Ltd. About IDAG Ltd. Multi-disciplinary Knowledge Mining and Integration Knowledge Measurement and Gap Analysis Knowledge Transfer Consulting, Mentoring, Troubleshooting Founded in 1983 Establishment of Microsoft University IL (1992) Project management mentoring, using Microsoft Solution Framework (MSF) Microsoft Solution Provider At least 25% of company time is dedicated to practical projects in order to acquire real-world experience

Copyright © 2003 by IDAG Ltd. … Why don’t you make mistakes ? Because I have a lot of experience ! How did you get your experience ? I did a lot of mistakes !!!

Copyright © 2003 by IDAG Ltd. Project Failure Rates Based on Application Development Projects, but Similar Numbers are in Deployment and Integration Projects Challenged Succeeded Failed 28% 46% 26%

Copyright © 2003 by IDAG Ltd. Success Hasn’t Come Easily %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 Source: The Standish Group International, Extreme Chaos, The Standish Group International, Inc., 2000 SucceededChallengedFailed

Copyright © 2003 by IDAG Ltd. What exactly do you mean by Challenged ? Challenged is the nice positive American way to tell you that you fucked the project Average cost overrun: 189% Projects re-started: 94% Time overrun: 222% Functionality delivered on average: 61% The truth is If a project is delivered on time, within budget and exactly according to the specifications, it is a miracle (miracle := 25%)

Copyright © 2003 by IDAG Ltd. “When projects fail, it’s rarely technical.” Jim Johnson, The Standish Group Root Causes of Failure Separation of goal and function The specification does not describe the real problem that the customer wants to solve Separation of business and technology The technology should serve the business and not become the reason for the change Lack of common language and process The development team doesn’t understand the business and interprets the specification wrong The process of the project is not clear to the customer and the team Failure to communicate and act as a team The team is not a team but a group of individuals pushing to opposite directions Processes that are inflexible to change When a change is needed in the specification, it can’t be done without actually restarting the project

Copyright © 2003 by IDAG Ltd. The problem is not new and the solutions are not new Use good methodology, PMI, CRM, BPR, EAI (Google search returns over 135,000 sites dealing with project management methodologies all of them promise the crystal ball) Learn the subject of project management Be an expert on the subject meters (anything connected to the project subject) Learn how to guide and lead people Learn Politics and Human resource management… Be a good psychologist, social worker, emphatic…

Copyright © 2003 by IDAG Ltd. The practical problem of a project leader It’s takes a Huge amount of Information and Knowledge to master and you don’t have time It’s easy to get lost in the translation of theory to practice and you don’t have enough experience You have to make a many decisions under time pressure and without enough information Methodology does not help a lot in day to day practical decisions You need something light, easy to use, simple, to show you the way when you are In doubt You need a Compass That’s exactly MSF

Copyright © 2003 by IDAG Ltd. Framework: Supplementing Methodologies 1st Avenue Plum Street Orange Street.. Smith River 2nd Avenue 3rd Avenue 4th Avenue..... S MSF. EW.. N.... The Methodology is the map with the instructions how to get there The framework is the compass that is always pointing to the target and show you the direction whenever you are lost

Copyright © 2003 by IDAG Ltd. 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

Copyright © 2003 by IDAG Ltd. 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

Copyright © 2003 by IDAG Ltd. Setting Expectations II I am not going to teach all MSF principles here and now it is a 4 days workshop I am going to show some of the principles and describe the logic behind them MSF is really just common sense pills to make your project healthier You don’t have to take it all at once, sometimes one good idea is enough to save you when you are alone in the dark

Copyright © 2003 by IDAG Ltd. Risk Management Discipline Process Model Team Model Project Management Discipline Readiness Management Discipline MSF Models and Disciplines Models Disciplines

Copyright © 2003 by IDAG Ltd. Where MSF Fits in the IT Life Cycle Microsoft Operations Framework Microsoft Solutions Framework Operate Deploy Build Plan

Copyright © 2003 by IDAG Ltd. MSF Process Model Is an Iterative Approach Time Functionality Minimize risks by breaking large projects into multiple versions Version 1 Version 2Version 3

Copyright © 2003 by IDAG Ltd. 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

Copyright © 2003 by IDAG Ltd. Making Project Trade-offs Resources Features Schedule

Copyright © 2003 by IDAG Ltd. 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 ??? …

Copyright © 2003 by IDAG Ltd. 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

Copyright © 2003 by IDAG Ltd. MSF Process Model Phases and Milestones Project Plans Approved Scope Complete Release Readiness Approved Deployment Complete Vision/Scope Approved MSF

Copyright © 2003 by IDAG Ltd. 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

Copyright © 2003 by IDAG Ltd. 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

Copyright © 2003 by IDAG Ltd. 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

Copyright © 2003 by IDAG Ltd. 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

Copyright © 2003 by IDAG Ltd. 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

Copyright © 2003 by IDAG Ltd. 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

Copyright © 2003 by IDAG Ltd. 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’…

Copyright © 2003 by IDAG Ltd. 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

Copyright © 2003 by IDAG Ltd. 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 Test Release Management User Experience Product Management Program Management

Copyright © 2003 by IDAG Ltd. 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

Copyright © 2003 by IDAG Ltd. Principles of a Successful Team Team of Peers Shared Product Vision Product Mindset Zero-Defect Mindset Customer-Focused Mindset Willingness to Learn

Copyright © 2003 by IDAG Ltd. Scaling for Small Projects Program Management Program Management Development Testing Logistics Management Logistics Management User Education User Education Product Management Product Management Program Management Program Management Development Testing Logistics Management Logistics Management User Education User Education Product Management Product Management No N Possible P Unlikely U P P P P P PP PP P U U UU U U U U N N N NN N N N N NNN

Copyright © 2003 by IDAG Ltd. User Experience Product Management Test Program Management Release Management Development Example: Small Teams Small team, combined roles

Copyright © 2003 by IDAG Ltd. 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

Copyright © 2003 by IDAG Ltd. 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

Copyright © 2003 by IDAG Ltd. Example: Function Team Group Product Management Evangelism Public Relations Marketing Product Planning Product Management Product Management

Copyright © 2003 by IDAG Ltd. 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

Copyright © 2003 by IDAG Ltd. MSF Readiness Discipline Knowledge Skills Abilities Assess Change Define Evaluate

Copyright © 2003 by IDAG Ltd. Courses 1846: Microsoft Solutions Framework Essentials 1737: Microsoft Operations Framework Essentials 1585: Gathering and Analyzing Business Requirements 1608: Designing Business Solutions 1609: Designing Data Services and Data Models All Syllabuses are available on Microsoft’s web site

Copyright © 2003 by IDAG Ltd. For More Information Web sites Microsoft Solutions Framework site at Steve McConnell’s Survival Guide site at Books Dynamics of Software Development, Jim McCarthy Rapid Development, Steve McConnell Software Project Survival Guide, Steve McConnell Debugging the Development Process, Steve Maguire Microsoft Secrets, Michael A. Cusumano and Richard W. Selby

Copyright © 2003 by IDAG Ltd. Call to Action Have management commitment If you need help call me Or Eran Kolber for a 1 hour presentation to management Find a Pilot project and assemble a team Train the team using certified trainer 4 days workshop based on 1846 Use one of the trainers or both as a consultant to mentor the team Just to verify that you are doing it right There are a lot of gray areas when you try to do it for the first time If the project succeeds, this team will be the base to build the other teams If the project fails, analyze the cause of failure and decide if you want to try again Remember, it is statistics and not a full guarantee

Copyright © 2003 by IDAG Ltd. Questions?

Copyright © 2003 by IDAG Ltd. Copyright © 2003 by IDAG Ltd. and Gad J. Meir. All rights reserved. (Some parts quote Microsoft public materials). This presentation, its workshops, labs and related materials may not be distributed or used in any form or manner without prior written permission by the author(s).