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.

Going Dark

“I’m twenty-five percent complete and on schedule,” reported Peter at the end of the first week of his four week task.  A week later, Peter reported “I’m fifty percent complete and on schedule.”  Some foreshadowing was offered in Peter’s report at the end of week three: “seventy-five percent complete, but I have some other things competing for my time next week.  I should be able to catch up, though.”  Then the bomb dropped on Wednesday, just three days later, when Peter finally had to face his deadline.  “It’s going to take me three more weeks to complete this.  I was going to use the API in the new version, but it’s returning the data in the wrong format and the vendor doesn’t have a patch, so I’ll have to rewrite it to use the old API and …”

I believe the phrase “going dark” originated with Jim McCarthy in Dynamics of Software Development (Microsoft Press, 1995).  As a guide for managing programmers, this classic is valuable still.  Rule number 30, Don’t Go Dark (pp 102-106), describes the hazards of failing to get regular, frequent, concrete evidence of a developer’s progress.  In this age of Agile, Scrum, RAD, RUP and other TLA methodologies, we project managers still allow team members to do this to us.  And not just in software development projects or by programmers.

There may be several different reasons to explain why a team member goes dark.  Maybe they don’t understand how to complete the task nearly as much as they thought they did.  Maybe they have 15 other things to do and this isn’t (from their perspective), the most important.  Maybe they don’t find the task as compellingly interesting as something else they can work on.  Maybe it’s a passive-aggressive way to make a point.  Often it is some combination of these – a less experienced team member, slightly over their head and with a seemingly endless list of must-haves from other managers, so they focus on doing what they can do rather than committing the time that’s needed to focus on this task.

It could be just the opposite, a team member who thinks they know how to complete the task and spends endless time searching false leads and dead ends without converging toward the solution.  For whatever reason, it needs to be recognized and addressed.  Fred P. Brooks, Jr., in The Mythical Man-Month (Addison-Wesley, 1975) documented the consequences of even slight slippages.  “How does a project get to be one year late” he asked.  “One day at a time.”

Regardless of why it may happen, appropriate planning and control protect us from these consequences.  A key task should have one owner, be no more than two weeks duration (about 65 effort hours if the owner is dedicated), and have a clearly defined Done state (see my previous entry).  That covers “appropriate planning.”  Appropriate control is to have an early warning system (which I will discuss in a future post) for when a task will be delayed so the delay can be addressed and corrected before it is a project problem.

Have you had a team member “go dark?”