Microsoft Solutions Framework

"The difference between a boss and a leader: a boss says, 'Go!' -a leader says, 'Let's go!'”

                                                                                                - E. M. Kelly

Sometime in a previous (professional) life, I worked for a company that used Microsoft Solutions Framework.  This was a very long time ago and I don’t even remember the company.  As a development framework, MSF didn’t really impress me much at the time, but there was one key element of MSF that did impress me and has stayed with me all of these years.

It may be that I wasn’t that impressed with MSF because the company that was using it wasn’t the best candidate for it.  MSF is ideally suited for software development for distribution (i.e., to consumers).  My client (employer?) was using it to develop software for internal use.  Further, they weren’t set up with the appropriate infrastructure and architecture for daily builds.  It was good they were using a development framework, but other choices would most likely have been more appropriate to their organization.

(This paragraph is an attempt at sarcastic humor.)  I have never used MSF in, what I would consider, an appropriate context for MSF.  However, Microsoft has years of success using it to deliver reliable, user friendly, quality software on schedule.  Therefore, I will accept their experience as its endorsement.

Nonetheless, I got training on MSF at my client.  As a framework and not a methodology, MSF is (intentionally and appropriately) light on the “how” of software development.  One area of the framework, however, is fleshed out in particularly specific detail:  the MSF Team Model.  The MSF Team Model has several favorable attributes:  it is specific about the roles (and responsibilities of those roles) that must be represented on the project team;  it is specific about the relationship of the team members to each other;   and it intentionally creates conflict between roles to establish natural “checks and balances.”

Prior to my training on MSF, my experience with building project teams was to have the “right” people.  But that is unabashedly vague.  Further, we may know that the team members we have are the right people, but how do we know what right people we might be missing?  The MSF Team Model resolved this weakness in my experience and practice.  Further, I know of no other framework or methodology that puts such emphasis on composing the team.

Therefore, as a Best Practice, I want to pass on the benefits of the MSF Team Model and strongly recommend that you consider the MSF Team Model on your projects.  More information on MSF and the Team Model is available in Microsoft Solutions Framework Essentials by Michael S. V. Turner (Microsoft Press, 2006).  Chapter 4 discusses building an MSF Team.

Have you had experience with MSF?  What is your opinion of the Team Model?

© 2013 Chuck Morton.  All Rights Reserved.